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SWEATING THE SMALL STUFF 



THE NEW YEAR'S TO-DO LIST 



2009 HAS COME AND GONE, 

and we enter a new decade of new 
challenges. But some of the old 
issues still linger. That's what I'd 
like to focus on this month— my 
pet peeves in modern games, 
most of which can be fixed now. 
We needn't wait until 2011! 

LACK OF STEREO 
DOWNMIXING 

I still play games on a two- 
speaker television, and so do a 
whole lot of other folks. Until the 
entire world has 5.1 surround, 
there needs to be a viable two- 
speaker option. It surprises me how 
many big budget games have this 
problem. Just the other day I was 
playing some ARMY OF TWO: THE 40TH 
DAY, and in the intra cinematic, I 
didn't realize until halfway through 
that there was a narration, because 
it was so low in the mix. Once the 
game started up, the in-game 
cutscenes were a bit better, but not 
by much— critical dialog about what 
to do and where to go was hard to 
hear unless I turned my character 
to the side of the one talking to me. 
From big budget games like FAR CRY 
2 to smallertitles like BLACK SITE: 
AREA 51, games continue to ignore 
the default audio setup of the 
average consumer. 

CONTEXTUALLY-DIFFERENT 
Ul BUTTONS 

You know those Windows 
Mobile smartphones which map 
the same buttons to different 
options in different contexts within 
the same program? And you 
know how everyone hates that? 
Consider this when designing 
menus and Ul, because a lot of 
games look a lot like Windows 
Mobile. DRAGON AGE is a game I 
love— I put in 60+ hours on the 
Xbox 360 version— but the menus 
are rather atrocious. 

Switching which buttons 
do what depending in whether 
I'm in a store or in the field, and 
not allowing use of items in 
organizational menus, but setting 



that to a separate subset of a 
different menu wheel ... it's just 
not a great idea. I think it says 
something about the maturity 
of our industry that a game can 
have an interface with that level 
of trouble and still be critically 
and commercially successful 
(and which I will play through to 
completion anyway). 

TEXTURE STREAMING 
» Storage has increased over 
the years, not only in terms of the 
physical disc media, but also the 
RAM and hard drives of consoles. 
So why are we still waiting several 
seconds for normals and textures 
to properly appear in many big 
name titles? Texture pop runs 
rampant through the industry, 
even when it comes to the 
largest and most accomplished 
companies. Some teams can do 
it, some can't. It does depend on 
what type of game you're making 
at times, but really, I'm not sure 
there's a context in which you 
absolutely couldn't fix this, given 
the time and dedication. 

NO TUTORIALS 
» It's amazingto think that in 
this day and age there are still 
some games that don't offer 
proper tutorials. Tutorials that are 
fun and properly integrated into 
the narrative are ideal, but even 
something that just tells me how I 
should play would be great. Some 
just throw you to the wolves. 

Picking on DRAGON AGE again, 
a certain level of knowledge was 
presumed, which when combined 
with the confusing menus, led to 
me not knowing how to use an 
item to heal my injuries until about 
10 hours in, when I just decided to 
fiddle with menus til I could find 
the option. The game did inform 
me that I should heal, but gave me 
no indication of how I should do it. 

Some folks made fun of the 
gated tutorial in HALO 2, in which 
you had to independently test your 
left and right analog sticks before 



proceeding into the single player 
campaign. But just last week I 
played LEFT 4 DEAD 2 with a person 
who had never touched a twinstick 
first person game before. For 
him, this would have been useful, 
because even though he intuitively 
knew where he wanted to go and 
where to aim, never having used 
both sticks before, the learning 
curve was very steep. 

LONG LOAD TIMES 
ON CONSOLE 

» I thought I'd end with some- 
thing to make everyone feel a 
little better about themselves, 
because it's tough to fix, and easy 
to shift the blame onto console 
makers. Load times are incredibly 
difficult to get rid of, and I don't 
expect they'll go away anytime 
soon. But there are things we can 
be doing with background loads, 
loading during cutscenes, more 
advanced streaming, or even 
reuse/recombination of assets 
(as is often done in open-world 
games). In the old days, we 
used to fear the "juggling mon- 
key"— the animated monkey that 
appeared on the loading screen 
of old Neo Geo CD games. In those 
days, you were waiting for several 
of megs of data to load— in the 
Dreamcast and PS2 era, loading 
came down a bit, but now it feels 
like I'm staring down that old jug- 
gling monkey once again. 

HIGH FIVES FOR A 
NEW FUTURE 

Games are getting more 
engrossing, more varied, and 
more complex, and I think the 
industry is moving in impressive 
directions. Every once in a while 
though, it's good to take stock of 
the things we still haven't fixed 
before we move on to what's next. 
And of course, this was only a 
fraction of what we need to work 
on— as luck would have it, there 
are only so many words I can fit 
on a page! 

—Brandon Sheffield 
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IGF finalists 




dependent 
Games Festival 
has announced the 
Main Competition 
finalists for the 
twelfth annual 
Dresentation of its 
Drestigious awards, 
celebrating the most 
innovative creations 
to come out of 
the independent 
game development 
community this year. 

Nearly $50,000 in prizes in 
various categories, including the 
$20,000 Seamus McNally Grand 
Prize, will be awarded on stage at the 
Independent Games Festival Awards 
duringthe 2010 Game Developers 
Conference in San Francisco. 

The record-setting 306 Main 
Competition entries represent a 35 
percent increase over last year's 226 
entries. To ensure the highest-quality 
judging for the IGF; more than 150 
leading indie and mainstream game 
industry figures— from 2D Boy's Ron 
Carmel through SPORE's Soren Johnson 
to ThatGameCompany's Kellee 
Santiago and beyond— were recruited 
to choose finalists via a carefully- 
constructed empirical process. 

In addition, for the first year, 
the IGF's Nuovo Award, intended 
to "honor abstract, shortform, and 
unconventional game development 
which advances the medium and 
the way we think about games," was 
judged by a separate, smaller juried 
panel of notable game and art world 
figures. These spanned previous 
IGF Nuovo winner Jason Rohrer 
(PASSAGE), Area/Code's Frank Lantz, 
N+ co-creator Mare Sheppard, EA 
division head and art-game creator 
Rod Humble, and more. 
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The finalists for the 2010 
Independent Games Festival are: 

SEAMUS MCNALLY GRAND PRIZE 

» JOE DANGER (Hello Games) 
» MONACO (Pocketwatch Games) 
» ROCKETBIRDS: REVOLUTION! (Ratloop Asia) 
» TRAUMA (Krystian Majewski) 
» Super Meat Boy! (Team Meat) 



EXCELLENCE IN VISUAL ART 

» SHANK (Klei Entertainment) 

» 0WLB0Y[D-Pad Studios) 

» TRAUMA (Krystian Majewski) 

» LIMBO (Playdead) 

» ROCKETBIRDS: REVOLUTION! (Ratloop Asia) 

EXCELLENCE IN DESIGN 

» MIEGAKURE (Marc Ten Bosch) 
» Star Guard (Sparky) 

» AAAAAAAAAAAAAAAAAAAAAAAAA! ! ! - 
A RECKLESS DISREGARD FOR GRAVITY 
(Dejobaan Games) 

» MONACO (Pocketwatch Games) 

» COGS (Lazy 8 Studios) 

EXCELLENCE IN AUDIO 

» Super Meat Boy! (Team Meat) 

» Shatter (Sid he) 

» CLOSURE (Closure Team) 

» ROCKETBIRDS: REVOLUTION! [Ratloop Asia) 

» TRAUMA (Krystian Majewski) 

TECHNICAL EXCELLENCE 

» CLOSURE (Closure Team) 

» LIMBO (Playdead) 

» Heroes Of newerth (S2 Games) 

» JOE DANGER (Hello Games) 

» VESSEL (Strange Loop Games) 

NUOVO AWARD 

» TODAY I DIE (Daniel Benmergui) 

» A SLOW YEAR (Ian Bogost) 

» TUNING (Cactus) 

» CLOSURE (Closure Team) 

» ENVIRO-BEAR 2000 (Justin Smith) 



All 2010 Independent Games 
Festival finalists will be awarded 
passes to GDC 2010 in San 
Francisco this March, where they 
will attend the 2010 Independent 
Games Summit— featuring two 
days of lectures and presentations 
from leading indie game 
developers. They will also be 
presenting playable versions of 
their game to all Game Developers 
Conference attendees at the IGF 
Pavilion on the GDC Expo Floor 
from Thursday, March 11th through 
Saturday, March 13th. 

The IGF 2010 winners will 
be announced on stage at the 
Independent Games Festival Awards 
on Thursday, March 11, 2010, at the 
Moscone Center. The IGF Awards, 
which kick off in North Hall D at 
6:30pm PST on the 11th, are held 
immediately preceding the 2010 
Game Developers Choice Awards, 
honoring the best games of the year 
from mainstream developers. 

"We're happy to report that 
the IGF has seen another record- 
breaking year in volume and 
diversity of entries, another 
symptom of the continuing 
explosion of high-quality titles 
from smaller development teams 
and emerging creators," said 
Simon Carless, IGF Chairman. 
"Congratulations to this year's 
outstanding finalists— we're 
looking forward to playingtheir 
games and honoringthe overall 
IGF winners at Game Developers 
Conference this March." 

The IGF was established in 
1998 by Think Services (which 
also owns Game Developer) to 
encourage innovation in game 
development and to recognize the 
best independent game developers, 
in the same way that the 




independent film community. 

Additionally, 10 winners of the 
2010 IGF Student Showcase have 
been announced, an event which 
recognizes outstanding indie game 
development taking place on school 
and university campuses around 
the world. 

The Student Showcase 
games— all of which will also be 
playable at the IGF Pavilion on the 
GDC 2010 show floor— were chosen 
from a remarkable field of entries by 
an opt-in subset of the more than 
150 notable game industry figures 
judgingthe IGF Main Competition. 

The full list of this year's 
winners is as follows: 

» BORYOKUDAN RUE (UCLA) 

» CONTINUITY (Chalmers University 

of Technology / University of 

Gothenburg) 
» DEVIL'S TUNING FORK (DePaul 

University) 
» dreamside maroon (DigiPen 

Institute of Technology) 
» IGNEOUS (DigiPen Institute of 

Technology) 
» Paper Cakes (Utrecht School of the 

Arts and USC) 
» PUDDLE (ENJMIN, France) 
» PUZZLE BLOOM (DADIU, Denmark) 
» SPECTRE (USC Interactive Media) 
» ULITSADlMITROVA(Kunsthochschule 

Kassel, Germany) 

Chosen from a new record of 190 IGF 
Student Showcase entries (up over 
30 percent on last year's 145 entries), 
these Student Showcase-winning 
games each win $500 and GDC 
2010 show passes, and will go on to 
compete for an overall Best Student 
Game prize, which includes a special 
trophy and a $2,500 cash prize. 

-Staff 
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2009 console market by the numbers 



2009 WAS A CURIOUS AND IMPORTANT YEAR FOR 

the game console market. Sony essentially 
relaunched its PlayStation 3 platform with the 
introduction of the PS3 Slim in August 2009. In 
September, the Wii dropped in price to $199. The 
Xbox 360 Pro model was eliminated in August and 
the Elite model was simultaneously reduced in 
price to $300 while the Arcade remained at $200. 

So what did this mean for sales? Sony moved 
2.39 million PS3s in all of October, November, 
and December 2009. It now appears that Sony 
actually has a price/value combination that can 
reach a much wider consumer market. 

During the same October-December period, 
Microsoft sold nearly the same number of Xbox 360 
systems (2.38 million). Forthesake of comparison, 
2.65 million units of Xbox 360 hardware were sold in 
the final quarter of 2008. The decline in final quarter 
sales comes in spite of Microsoft's modest shifts in 
model and price positioning. 

Here's a look at sales for each year since 
2005 across all models of console hardware: 

Annual Console Hardware Totals, 2005 - 2009 
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While the Wii experienced a drop in sales from 
2008 to 2009, it could certainly do well in the 
coming months. The key is timing. Recall that as 
of the end of September 2009, the system's year- 
to-date (YTD) sales were 22 percent behind those 
of the same period in 2008. By year's end the Wii 
was only behind its 2008 total by 57 percent. 
Similarly, Sony's Slim moved PS3 hardware sales 
from a 32 percent deficit at the end of July to a 22 
percent gain by year's end. 

For a larger perspective, here's overall first 
and third party game industry revenue by 
hardware manufacturer for 200? through 2009: 
Estimated Industry Revenue by Platform Holder 
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Microsoft sold more hardware and software 
on its platform in 2009 than it did in 2008, so it 
seems the Xbox 360 hardware price cuts drove 
most of that drop in revenue. Similarly, the Wii 
price cut no doubt explains most of the fall in 
Nintendo's revenue, which also includes DS 
hardware, software, and accessory numbers. The 
DSi exceeded 5 million units by itself, contributing 
to a total of 11.2 million DS units sold in 2009. 



The more worrying figure is the $1.3 billion 
drop in Sony's revenues from its line of PlayStation 
systems. Based on comments made by Wedbush 
Morgan analyst Michael Pachter, it's estimated 
that PlayStation 2 software revenues dropped by 
around $700 million in 2009, compared to 2008. 
That decline alone would explain more than half 
of Sony's loss. The PlayStation 2 hardware also 
received a price cut in 2009, which could have 
contributed another $150 million in lost revenue. 
Another $225 million or more may have come from 
an annual loss of 1.3 million PSP system sales. 
According to Creutz of Cowen & Company, the 
handheld software segment shed $200 million 
in annual revenue from 2008 to 2009, and we 
estimate at least half of that loss can be attributed 
to declining PSP software sales. 

The general shape of the console landscape 
going into 2010 is this: the PlayStation 3 is in a 
position to grow, and in fact must, to bring the 
company's revenues back up. The PSP business 
is in need of a revamp, one with a greater 
cost/value ratio than the PSP Go. Microsoft is 
performing well, with its single console, but needs 
to maintain the momentum it built up before 
the release of the PS3 and Wii. Nintendo for its 
part must capitalize on the new system sales of 
late 2009 with software, and perhaps another 
strategic price cut later in the console's life. 2010 
promises to be a very interesting year for the big 
three console makers. —Matt Matthews 



2D flash library flashpunk released 



ADAM SALTSMAN'S FLIXEL WAS THE 

first major free library to come along 
for flash, enabling game makers 
to create 2D games in much less 
time than before. Now, Chevy Ray 
Johnston has created an alternative 
to Flixel in Flashpunk, a 2D-oriented 
library that relies heavily on the use 
of bitmaps, allowingthe display of 
thousands of objects on screen at a 
fixed frame rate. 

Johnston has written up the 
differences between the two 
libraries on the TIGSource indie 
game forums— here's an example: 

"FlxSprites, by default, have a 
single bitmap they are assigned 
with several images, and you 
can create animations using 




Chevy Ray Johnston's Fight! Mechanical 
Shooting Device 



arrays to cycle through those 
images in a particular order. 
FlashPunk works differently in 
this department. Because of the 
nature of my programming, I am 
used to assigning sprites with 
origin-values, or 'hotspots.' This 
basically represents the (0, 0) origin 
of the sprite, so if a 16x16 sprite 



has an origin at 8x8, [depending on 
where] you place that sprite, and 
the 16x16 sprite will be centered on 
that position. Sprites are managed 
through a SpriteMap class, and each 
of your game Entities can have as 
many SpriteMaps as you want (each 
with their own origin, image-count, 
et cetera). So each animation would 
be a separate SpriteMap, and a 
player might have a Jump, Walk, 
and Idle sprite that it can switch 
between. Because you can also set 
'origins' on these sprites, when you 
draw a sprite rotated, for example, 
you can specify whether you want 
to draw that sprite rotated around its 
center, or rotated around its origin. 
So basically you are able to natively 



set a 'pivot' point from which you 
can rotate or scale the sprite." 

Flashpunk currently lacks 
some of the bells and whistles 
of Flixel, namely the more robust 
physics, but does boast active z- 
sorting for objects, and rectangle 
or pixel-perfect collision detection, 
which Johnston promises is 
extremely fast. 

For now, the community is small, 
but multiple free libraries for Flash 
can only be a good thing, enabling 
more developers, both indie and 
professional, to create games faster. 
FlashPunk can be found here: http:// 
flashpunk.net. Flixel is available at 
this address: http://flixel.org. 

—Brandon Sheffield 
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Game Developers Conference 2010 Preview 




IT'S THAT TIME OF YEAR AGAIN-TIME TO PLAN TO MEET UP WITH OLD FRIENDS (BUT NOT ACTUALLY BE ABLE TO); TIME TO ACCIDENTALLY 

complain at a party about a game being horrible to someone who worked on it; time to look for work while pretending not to look forwork; 
time to realize just how many males there are in this industry. It's time for GDC! 

In 2009 there was an increased emphasis on new and independent studios, though the blockbusters still made the headlines. In 
2009 the iPhone game market was proved (and flooded), XBLA games proved they could sell over a million, and Steam and Direct2Drive 
dominated much of the PC game selling space. With this in mind, a lot of folks kicked off the shackles of their bloated parent companies 
and started nimble indie developers, and failed miserably, or succeeded grandly. 

2009 was also the year of Facebook and social games coming into their own, and proving profitability. The new Social and Online Games 
Summit addresses this market as it increases in importance and scope. 

New trends aside, the 2010 GDC will host tons of talks on the traditional industry, as well as provide summits and tutorials for a more in- 
depth study of certain techniques or aspects of development. In the following pages, the editors of Gome Developer and Gamasutra.com 
have compiled our picks for the most interestingtalks across all disciplines (as of press time, not all talks have been announced). 

With any luck, this will help prepare you for the onslaught of knowledge, sights, and fanboys the conference has to offer (this is also a 
good time to revisit the GDC game at www.gamesetwatch.com/gdcgame). See you there! —Brandon Sheffield 
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GDC PHOTOS BY VINCENT DIAMANTE 






Editor-in-Chief 
BRANDON SHEFFIELD 

THE RENDERING TOOLS AND TECHNIQUES OF SPLINTER CELL: 
CONVICTION (LECTURE) 
Stephen Hill (Ubisoft) 

Anyone who's seen the new trailers for SPLINTER CELL: CONVICTION knows 
the art department is doing something right. The game looks gorgeous, 
has new ideas about lighting-based level objectives, and generally raises 
the bar for blockbuster game visuals. In this talk, tech lead Stephen 
Hill will discuss the renderingtechniques that make this happen, from 
ambient occlusion to visual depth. 

FATE OF A SMALL SOCIAL GAME STUDIO (LECTURE) 
Justin Hall (GameLayers) 

GameLayers raised $2 million as a startup, at one point having nine 
employees, intending to make a browser-based MMO in a Firefox 
toolbar. Two years later, in 2009, the company had no Firefox MMO, 
but two Facebook games. Now, in 2010, the company principals are 
looking for jobs. What happened? Justin Hall will share tips from his 
experiences, from raising money, to managing and creating a small 
company, to what breaks it apart. 

GO WITH THE FLOW! FLUID AND PARTICLE 
PHYSICS IN PIXELJUNK SHOOTER 
(LECTURE) 

Jaymin Kessler (Q-Games) 

Kyoto-based Q-Games has long been 
interested in marrying the hardest-core codey- 
ty pes with interesting design, and nowhere 
is that more evident than in PIXELJUNK 
SHOOTER. This techy talk will go in-depth 
on the game's fluid and particle systems, 
including SPU and GPU distance algorithms for 
collision detection, particle fluid rendering technology, and even design 
considerations for mixing dissimilar fluids. 

WHAT HAPPENED HERE? ENVIRONMENTAL STORYTELLING 
(LECTURE) 

Harvey Smith (Arkane Studios), Matthias Worch (Visceral Games) 

As the title suggests, smart fellows Harvey Smith and Matthias Worch 
will sharing their ideas for how environment can be used in storytelling, 
as is done so well in games like PORTAL on a smaller scale, and FALLOUT 
3 on a larger (and perhaps less-structured) scale. I will also use this 
space to challenge Worch to justify the overkill environmental, aural, and 
textual "shoot off their limbs" reminders in the tutorial phase of DEAD 
SPACE. Go! 

HOW OUR CENTRALIZED TECHNOLOGY GROUP JEOPARDIZED OUR 
DELIVERIES (LECTURE) 
FredrikSjoo (Avalanche Studios) 

More and more companies have been running up against difficulties 
with centralized technology groups. The recent TOMB RAIDER 
postmortem mentions it, it's one of the factors that took down Midway, 
and now Avalanche is telling its own tale. It's not that centralized 
technology is bad in itself— but unless it's set up right, you have 
a rogue band of coders who answer directly to no-one, yet must 
ultimately serve everyone. 




Production Editor 
JEFFREY FLEMING 

COMPOSER CHALLENGE GDC 2010 (PANEL) 
Lennie Moore (Independent Composer) 

The challenge for game composers this year was to re-imagine the 
PAC-MAN theme for a new decade. Working from the original theme, 
13 composers submitted their 60-second interpretations to a vote by 
Game Audio Network Guild members. The creators of the top three sub- 
missions will be at GDC to present their work and discuss their compo- 
sitional process. Then they will face off against last year's winner Mick 
Gordon to determine the new king of all bleep. Be sure to listen to the 
13 entries at www.lenniemoore.com/GDC2010CC.html. 

CREATING THE ACTIVE CINEMATIC EXPERIENCE OF UNCHARTED 2: 

AMONG THIEVES (LECTURE) 

Bruce Straley and Neil Druckmann (Naughty Dog) 

While FMVmay be a thing of the past, the basic idea of seeding static 
cutscenes throughout gameplay continues to be the industry's go-to 
technique for conveying narrative. However, more nuanced methods 
that intertwine play with story are being attempted and narrative is 
fast becoming integral to game mechanics. In this talk, the designers 
of UNCHARTED 2: AMONG THIEVES will explore some of the techniques the 
studio borrowed from traditional storytelling to bring emotional weight to 
the video game action. 

EXPERIMENTAL GAMEPLAY SESSIONS (PANEL) 
Jonathan Blow (Number None) 

Tough economic times are inevitably conservative times. The game 
industry, which is already deeply risk-averse, will have an even greater 
focus on producing safe, familiar products that will be an easy sell for 
the months (and possibly years) to come. This makes efforts like the 
Experimental Gameplay Sessions absolutely essential forthe long-term 
health of the industry. Moderated by Jonathan Blow, the two-hour panel 
will give game creators a chance to present their most challenging ideas 
and explore new design modes. 

THE ART OF WAR: EFFECTIVE WAYS TO ADDRESS THE RMT ISSUE 
(LECTURE) 

Eyjolfur Gudmundsson and EinarSigurdur Hreidarson (CCP) 

Real money traders (RMTs) are almost universally looked at as scourge 
by MMO developers. The problem may be obvious but combating it is 
never simple. In this lecture Eyjolfur Gudmundsson and Einar Sigurdur 
Hreidarson of CCP will share the results of operation "Unholy Rage," a 
multilevel approach to eliminating RMTs from EVE ONLINE that combined 
techniques for indentifying and banning RMTs with systems that 
incentivise players away from shady Interstellar Kredit dealers. 

PROCEDURAL, THERE IS NOTHING RANDOM ABOUT IT (LECTURE) 
Eskil Steenberg (Independent Developer) 

Procedural content generation has the potential to level the mountain 
of asset creation and empower small developers, allowing them to 
create on scale far larger than would otherwise be possible with limited 
resources. Procedural content also opens up intriguing, and largely 
unexplored paths in game design and art direction. Eskil Steenberg's 
LOVE is a one-man effort at creating a procedurally generated MMO 
and he'll be discussing the techniques he used to synthesize its 
impressionistic world. 




WWW.GDMAG.COM 




ENGINEERING SCALABLE SOCIAL GAMES (LECTURE) 
Robert Zubek (Zynga) 

Zynga's Facebook games are the most popular on the service— and 
many of its titles have tens of millions of monthly active users. How do 
you provide an infrastructure that can handle that many users, scaling 
up that quickly? In this session, Zubek outlines how engineering 
practices taken from the web and game worlds unite to support these 
massive audiences— info which might also prove useful to engineers 
working on online products outside of the Facebook model. 

FINAL FANTASY XIII'S MOTION-CONTROLLED REAL-TIME AUTOMATIC 

SOUND TRIGGERING SYSTEM (LECTURE) 

Yoshinori Tsuchida and Tomohiro Yajima (Square Enix) 

FINAL FANTASY XIII is all about characters interacting— both in combat 
and in story. The team has shifted a great deal of emphasis to doing 
that in real time, within gameplay, both in exploration and in battle. 
Characters speak while exploring or cry for help— much more subtly 
and seamlessly than most games. Good, then, that an engineer and 
sound director from the team have united to give this talk which 
explains the scripting-based solution that arose to handle the task. 
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SQUARE PEGS ROUND HOLES, 
INTEGRATING A WRITER INTO YOUR 
TEAM (LECTURE) 

Marianne Krawcyzk (Monkeyshines 
Entertainment) and Susan O'Connor 
(Susan O'Connor Writing Studio) 

Like many game writers, Krawcyzk 
(GOD OFWAR series) and O'Connor (FAR 
CRY 2) have discovered that the increasing need for effective narrative 
exists in games, but that the processes for working with the teams on 
projects are just not as robust as other elements of game direction. In 
this session, the two promise to share candid stories about the travails of 
getting it up and running, while offering advice to producers, writers, and 
designers about how best to smooth out the collaborative process. 

MODELING INDIVIDUAL PERSONALITIES IN THE SIMS 3 (LECTURE) 
Speaker: Richard Evans (Maxis) 

THE SIMS series would be nothing without the characters that inhabit 
its world, and since they're Al constructs, a great deal depends on 
executing complicated Al technology. The challenge is delivering that 
complexity via tools designers and producers, not programmers, must 
use. Here, Maxis' lead simulation engineer promises to demonstrate 
the tools the team used to deliver its world of virtual people. 

CHARACTER VOICES: CONCEPTUALIZATION, CASTING, RECORDING, 
AND THE CULTURAL REFERENCE POINT (LECTURE) 
Zach Hanks (SOUNDAWG) 

While it's true that better dialogue writing will only improve the 
believability and engagement of game stories, a lot of personality is 
injected in the recording studio. As with writing, though, the art of the 
process isn't always fully understood by everyone involved. Here, 
Hanks will outline what needs to happen before recording begins— 
conceptualizing the character backgrounds, casting the right actors, 
and preparing for the recording session. 



Gamasutra Editor-at-Large 
CHRIS REMO 

CRUSHING THE OVERHEAD: CASE STUDY OF A MICROSTUDIO START- 
UP (LECTURE) 
Randy Smith (Tiger Style) 

Upon its release, Tiger Style's debut iPhone game SPIDER: THE SECRET 
OF BRYCE MANOR became a critical and commercial hit, earning 
praise for its natural gameplay and subtle narrative conceits. In this 
presentation, founder and designer Randy Smith— an industry veteran 
whose credits include the THIEF series— will discuss the lessons 
learned from Tiger Style's business and management approaches, 
which keep overhead costs to an absolute minimum. 

ROCK SHOW VFX-THE EFFECTS THAT BRING BRUTAL LEGEND TO LIFE 
(LECTURE) 

Peter Demoreuille and Drew Skillman (Double Fine Productions) 

BRUTAL LEGEND'S unconventional blending of real-time strategy and 
action/adventure elements received mixed reviews from some 
quarters, but the game's visual depiction of its epic, sprawling heavy 
metal landscape is an unmitigated triumph. In this talk, Double Fine 
programmer Peter Demoreuille and effects artist Drew Skillman 
will drill down into the studio's effects creation process, explaining 
how they used rapid development without sacrificing usability and 
performance. 

WHY OWNING YOUR OWN IP IS A BAD IDEA: GIVING UP YOUR RIGHTS 

FOR FUN AND PROFIT (LECTURE) 

Chris Charla (Foundation 9 Entertainment) 

It's one of the most common pieces of advice given to independent 
studios: "Hold on to your intellectual property." But Foundation 9 
Entertainment has managed to become one of the world's largest 
and most successful independent development groups while largely 
ignoring that maxim. Business development VP Chris Charla will 
discuss why owning IP is unnecessary for independent studios— and 
may be actively harmful to their commercial prospects and business 
opportunities. 

YOUR GAME IS LIVE, NOW WHAT? LESSONS LEARNED IN THE 
ONLINE WORLD (LECTURE) 
Jane Fraser (Electronic Arts) 

In the rapidly evolving world of online games, titles aren't done when 
they "ship"— they're just getting started. And because online games 
end up under ongoing development, good QA is absolutely necessary. 
In this lecture, Electronic Arts' OA director Jane Fraser will discuss QA 
and production processes employed by EA for its online-driven Pogo 
and Social divisions. 

C++ IS A BAD LANGUAGE FOR GAME DEVELOPMENT-WHAT SHOULD 
REPLACE IT? (LECTURE) 
Mark Baker (Black Rock Studio) 

What language is more ubiquitous than C++? After all, it's been in 
commercial use for well over two decades— but that's exactly the 
problem, according to lead programmer Mark Baker of PURE and SPLIT/ 
SECOND developer Black Rock Studio, who points out that the needs 
of modern game development demand alternatives. In a roundtable 
discussion, Baker and session attendees will consider how C++'s 
shortcomings can be addressed, and what languages might succeed it. 
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GIVE SPREADSHEETS 
THE BOOT! 
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DevTest Studio t 

The. game industry's #1 cWceTorte^ defect ticking. 



DevTrack 

Use DevTrack to track defects/issues 



• Track each issue through a definable • 
workflow 

• SCM integration-track fixes against their 
source code deliverables 

• Deploy a resolution across multiple releases, 
versions and products 

• Reporting and metrics to illustrate the entire 
defect lifecycle 



DevTest 

Use DevTest to manage your testing 



Create a central repository for your test 
cases, Knowledge items and automation 
scripts 

Schedule releases and test cycles using a 

wizard-driven interface 

Execute test assignments and submit defects 

from the same interface 

Track results with real-time dashboards and 

reports 



TestLink 

Use TestLink to automate your testing 



■ Add automated tests to the DevTest test 
library 

• Schedule automated tests along with 
manual tests 

• Launch automated tests from the DevTest 
interface 

• Track automation results with real-time 
dashboards and reports 



Try DevTrack and DevTest live. Download free evaluation software. Watch a recorded overview demo 

www.techexcel.com 



TechExeel I 1-800-439-7782 





Gamasutra Senior Contributing Editor 
KRIS GRAFT 

ART DIRECTION TOOLS FOR PHOTO REAL GAMES (LECTURE) 
Henry LaBounta (Electronic Arts Black Box) 

EA Black Box is known for its work on the NEED FOR SPEED and SKATE 
series, both of which have relied on a realistic visual style. EA's 
LaBounta will talk about new ways of capturing and creating accurate 
textures and other aspects of a visually appealing game that's true to 
life. LaBounta's lecture promises to offer practical advice on ways to 
analyze and understand images, and why they may or may not work. 

DEVELOPMENT TELEMETRY IN VIDEO GAMES PROJECTS (LECTURE) 
GeorgZoeller (BioWare Austin/EA) and Paul Roffel (BioWare 
Edmonton) 

With game development growing to incredible levels of complexity, 
managing the workflow is more important than it has ever been. Georg 
Zoeller and Paul Roffel are familiar with this complexity, working at 
BioWare, developer of sprawling games like DRAGON AGE and MASS 
EFFECT. The two will talk about managing such massive workloads, 
gathering production data, and applying it to the development process. 

OA'S 10 COMMANDMENTS: WHAT?! ONLY 10? (LECTURE) 
Chuck McFadden (Sony Computer Entertainment America) 

How well-integrated into your production pipeline is QA? Be honest 
now. How many of those poor bastards are plugging away at 12 am 
because a build wasn't ready forthem until 11 pm? McFadden's 10 
commandments of OA should help anyone interested in the OA process 
to make their team run smoother. 

THE ASSET PIPELINE FOR JUST CAUSE 2: LESSONS LEARNED 
(LECTURE) 

Mathias Westerdahl (Avalanche Studios) 

This lecture from Avalanche Studios gives an overview of the asset 
conditioning pipeline in the multiplatform action game JUST CAUSE 2. 
"Streamlining" is the key word here, and Mathias Westerdahl will pull 
from his own personal experience to explain the process the studio 

used to analyze and remove 
pipeline bottlenecks, and make 
the pipeline generally more 
flexible. 

BUILDING A BETTER HALO WITH 
PYTHON: PRODUCTION PROVEN 
TECHNIQUES (LECTURE) 
Seth Gibson (343 Industries) 

In this technical lecture, Seth 
Gibson will offer insight into 
how many of Python's more 
specialized facilities can be used 
to perform many digital content 
creation-related tasks much 
more efficiently than the DCC 
app's native paradigms. Through specific working examples, Gibson will 
also give insight into how these techniques can be used to enhance 
existing tools or develop new tools. He'll also highlight incentives for 
users to explore Python's built-ins on their own, and incorporate their 
findings into their own pipelines. 





Gamasutra News Director 
LEIGH ALEXANDER 

GDC MICROTALKS 2010: TEN SPEAKERS, 200 SLIDES, LIMITLESS 
IDEAS! (ROUNDTABLE) 

Richard Lemarchand (Naughty Dog), Ian Bogost (Georgia Institute 
of Technology), Heather Chaplin (journalist/author), Chaim 
Gingold (levity lab), Gary Penn (Denki), Sam Roberts (indiecade. 
com), Margaret Robertson (Lookspring), Kellee Santiago 
(thatgamecompany), Suzanne Seggerman (Games for Change), 
Jesse Schell (Carnegie Mellon, Schell Games) 
What can notable designers teach you in five minutes and twenty 
seconds each? Naughty Dog's Richard Lemarchand wrangles nine 
notables including Ian Bogost, Kellee Santiago, Margaret Robertson and 
more for a short-format group lecture with rapid-fire visuals and a wide 
range of ideas, presented in a game-like format designed to provoke 
thought and discussion. 

THE IMPLEMENTATION OF REWIND 
IN BRAID (LECTURE) 
Jonathan Blow (Number None) 

The ability to literally "rewind" 
gameplay is crucial to BRAID both 
mechanically and narratively, 
but how was it achieved? Creator 
Jonathan Blow explains the robust 
system by which exact reproductions of up to 60 minutes of gameplay 
could be made to fit in such a small file (40 MB), how it was developed, 
and the challenges along the way— including other potential models 
that were investigated and discarded. 

FREE TO PLAY, PAY FOR STUFF: VIRTUAL GOODS GO BOOM! (LECTURE) 
Daniel James (Three Rings) and Matt Mihaly (Sparkplay Media) 

By now, everyone's heard that virtual goods are the "next big thing" 
in monetizing online games, but much discussion remains around 
the major factors in play. Three Rings' Daniel James and Sparkplay 
Media's Matt Mihaly lead the discussion on the dynamics and pitfalls of 
this business model. James and Mihaly will hit on topics such as real 
money trading, designing for microstransactions, and whether selling 
virtual goods is bad for gameplay. 

FIVE WAYS A VIDEO GAME CAN MAKE YOU CRY (LECTURE) 
Richard Rouse III (Kaos Studios/THQ) 

Whether games can make players cry is often a measure of their 
narrative impact, but it's more complicated than that. Kaos Studios' 
Richard Rouse III looks at what media of all kinds have learned about 
provoking intense emotion, deconstructing specific examples to 
discoverthe place where design and human emotion cross paths. 

FAMOUS LAST WORDS LIVE: AN OPEN MIC TO DISCUSS ANY AND ALL 
GAMES INDUSTRY LEGAL OR BUSINESS QUESTIONS, TRENDS, AND 
CONCERNS (ROUNDTABLE) 
Jim Charne (lawyer) 

Legal and biz expert Jim Charne throws the doors open for attendees 
at an open mic roundtable, where he's ready to field any and every 
participant question related to the business of game development. 
Nothing's off limits, and attendees won't want to miss their chance to 
benefit from Charne's expertise. Who doesn't want free advice? 
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Summits 



The first two days of GDC are traditionally organized around summits that feature lectures, panels, and hands-on workshops 
addressing specific cross-sections of the industry. Getting down to the brass tacks with your contemporaries should prove to 
be challenging and creatively invigorating. Here are just a few of the highlighted sessions from this year's summits. 



Al SUMMIT 

EXPERIMENTAL GAME Al: 
LIVE DEMOS OF INNOVATION 
(LECTURE) 

Richard Evans (Maxis), 
Ian Holmes (UCB),Adam 
Russell (University of 
Derby), Michael Mateas 
(UCSC), Steve Rabin 
(Nintendo of America) 
Here's a unique opportunity 
to see the latest Artificial 
Intelligence experiments 
coming out of academia 
and industry R&D demon- 
strated first-hand. These 
techniques may not all 
make it to your next game 
but seeingthem in one 
place is sure to generate 
some fresh thinking on Al. 

WHY SO WARY OF Al 
MIDDLEWARE? (PANEL) 
Steve Gargolinski (Blue 
Fang Games), Chris Jurney 
(Double Fine Productions), 
Brett Laming (Rockstar 
Leeds), Borut Pfeifer (Plush 
Apocalypse Productions), 
John Funge (Netflix) 
While there are successful 
middleware solutions for just 
about every aspect of devel- 
opment, Al middleware has 
yet to gain full acceptance 
from game creators. Listen in 
to the experiences— both pro 
and con— with Al middleware 
from this panel of industry 
veterans. 

GDC MOBILE/HANDHELD SUMMIT 
GHOSTWIRE: CREATING 
AUGMENTED REALITY 
EXPERIENCES ON 
NINTENDO DSI (LECTURE) 
Tom Soderlund (A Different 
Game) 

The upcoming GHOSTWIRE 
is an intriguing game that 
takes advantage of the 
Nintendo DSi camera and 
allows players to hunt 
through their real world sur- 
roundings for ghosts. Here 
Tom Soderlund gives a look 



into the design challenges 
and opportunities presented 
by the DSi hardware. 

MAXIMIZING SALES AND 
DOWNLOADS FOR INDIE 
MOBILE GAME DEVELOPERS 
(ROUNDTABLE) 
Aaron Isaksen (AppAbove 
Games) and Dave 
Castelnuovo (Bolt Creative) 
Getting players to fork over 
good money for mobile 
games can be problematic 
and it is critical for develop- 
ers on a limited budget to 
make every penny count 
when planning their dis- 
tribution and marketing 
strategies. 

GAME LOCALIZATION SUMMIT 
ADVANCED LOCALIZATION 
METHODS FOR JAPANESE 
GAMES (PANEL) 
Peter Fabiano (Capcom), 
Fabio Minazzi (Binari 
Sonori), Mark McDonald 
(Alien Technology) 
If you want to reach beyond 
a niche audience, a good 
localization is crucial to 
your game's success. 
Although targeted toward 
Japan-based titles, this 
panel should serve anyone 
looking to reach a global 
audience. 

STANDARDIZING THE 
LOCALIZATION PROCESS 
(LECTURE) 

David Kim (Sony Online 
Entertainment) 

With a number of MMOs 
in the works Sony Online 
Entertainment has had to 
standardize its localization 
efforts in order to target 
simultaneous worldwide 
launches. In this lecture 
David Kim will describe 
Sony's efforts to standard- 
ize its text engine, data 
exchange formats, and 
content tools. 



IGDA EDUCATION SUMMIT 
GLOBAL GAME JAM BLASTS 
(LECTURE) 

Gorm Lai (co-founder 
Global Game Jam), 
Ian Schreiber (Game 
Developer & Professor), 
Foaad Khosmood (UC 
Santa Cruz) 

Game jams, including the 
massive Global Game Jam, 
can provide an excellent 
resource for educators. 
With a philosophy of 
encouragement and shared 
knowledge, game jams can 
bridge the gap between the 
classroom and real-world 
game development. 

INDUSTRY AND ACADEMIA: 
IN SEARCH OF THE LOVE 
(PANEL) 

Drew Davidson (Carnegie 
Mellon University), Greg 
Foertsch (Firaxis Games), 
Tracy Fullerton (USC 
Interactive Media), Colleen 
Macklin (Parsons the 
Newschool for Design), 
Walter Rotenberry (Wake 
Tech Community College) 
The academic study of 
games can often seem 
far removed from the day- 
to-day realities of game 
development. In this panel 
academia and industry will 
discuss productive ways to 
bridge this gap. 

INDEPENDENT GAMES SUMMIT 
EFFECTIVE MARKETING FOR 
INDIE GAME DEVELOPERS 
(LECTURE) 

John Graham (Wolfire 
Games) 

After months of toil 
you've created a work of 
heartrending genius. Now 
what happens? Wolfire's 
John Graham will talk you 
through it, explaining what 
worked and what didn't in 
marketing the indie game 
Overgrowth. 



POSTMORTEM: THE DESIGN 

& BUSINESS BEHIND 

FANTASTIC CONTRAPTION 

(LECTURE) 

Colin Northway and 

Andy Moore (Fantastic 

Contraption) 

Fantastic Contraption began 
life as a free, Flash-based 
webgame. It has since 
turned into a big money 
maker for its creators. This 
postmortem will explore the 
design constraints of Flash 
the game's transition into a 
paying proposition. 

IPHONE GAMES SUMMIT 
A BIG DASH OF SUCCESS: 
HOW TO CAPTURE THE 
FEMALE IPHONE GAMER 
(LECTURE) 

Chris Williams (PlayFirst) 

According to PlayFirst, over 
90 percent of DINER DASH 
players are women. Here is 
an opportunity to examine 
the company's detailed 
analytics gathered on the 
female iPhone audience. 

THE IPHONE CONTRACT: 
WHAT YOU SHOULD HAVE 
READ (LECTURE) 
Mark Methenitis (The 
Vernon Law Group) 
If you are an iPhone devel- 
oper you will want to read 
your contract very carefully. 
In this lecture, attorney 
Mark Methenitis will walk 
you through the Registered 
iPhone Developer 
Agreement and the iPhone 
Developer Program License 
Agreement. 

SOCIAL & ONLINE GAMES SUMMIT 
OPEN SOURCE SECRETS: 
THE SOFTWARE 
ARCHITECTURE BEHIND 
A SUCCESSFUL VIRTUAL 
GOODS BUSINESS 
(LECTURE) 
Timothy Fitz(IMVU) 
Open Source software is 
increasingly accepted by 



the game industry as a 
viable tool for building a 
healthy business. In this 
lecture Timothy Fitzwill 
give a detailed look at build- 
ing IMVU's architecture with 
open source code, includ- 
ing the graphic engine and 
user interface framework. 

HOW TO INNOVATE IN 
THE LAND OF CLONES 
(LECTURE) 

Nick Fortugno (Playmatics) 

Here, Nick Fortugno propos- 
es that a successful social 
game design philosophy is 
built on understanding the 
basic player motivations 
and desires that carry over 
from game to game and 
then seeking novel ways to 
satisfy them. 

SERIOUS GAMES SUMMIT 
CODE OF EVERAND: 
DESIGNING THE SERIOUS 
CASUAL MMO (LECTURE) 
Kevin Cancienne (Area/ 
Code) 

Teaching road safety to 
children by fully embracing 
the limitations of its subject 
matter, Area/Code presents 
an MMO that is fun to play 
while retaining a serious 
purpose. 

THEME IS NOT MEANING 
(LECTURE) 

Soren Johnson (EA Maxis) 

This Serious Games 
Summit Keynote from EA 
Maxis designer and Gome 
Developer columnist Soren 
Johnson examines the rela- 
tionship between a game's 
stated theme and the mean- 
ing that emerges naturally 
from its rules. Of particular 
concern to serious games 
developers, when these 
are in conflict the resulting 
game can be a dissonant 
experience that often fails at 
instructing players. 

—Jeffrey Fleming 
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Unreal Technology News 

by Mark Rein, Epic Games, Inc. 



Canadian-born Mark Rein is 
vice president and co-founder 
of Epic Games based in Cary, 
North Carolina. 

Epic's Unreal Engine 3 won 
Game Developer magazines 
Best Engine Front Line A ward 
for three consecutive years, 
and it is also the current Hall of 
Fame inductee. 

Epic's internally developed 
titles include the 2006 
Game of the Year "Gears of 
War"forXbox360 and PC; 
"Unreal Tournament 3" for 
PC, PlayStation 3 andXbox 
360; and "Gears of War 2" for 
Xbox360. 



Upcoming Epic 
Attended Events: 

DICE Summit 

Las Vegas, NV 
February 17-19, 2010 

GDC 2010 

San Francisco, CA 
March 9-13, 2010 

Triangle Game Conference 

Raleigh, NC 
April 7-8, 2010 

E3 2010 

Los Angeles, CA 
June 15-17, 2010 

Please email: 
mrein@epicgames.com 
for appointments. 
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UNREAL 



UDK-POWERED DUNGEON DEFENSE AVAILABLE 
NOW FOR FREE DOWNLOAD 

Several games created with the Unreal Development 
Kit (UDK) have been released since the free Unreal 
Engine 3 toolset's November launch, and loads of new 
projects are in the works. 

This month, we would like to introduce you to Dungeon 
Defense, Trendy 
Entertainment's 
game that combines 
tower defense 
strategy with action 
RPG gameplay in 
a stylized fantasy 
setting. 

In Dungeon 
Defense, players 
fend off hordes of 
invading baddies 
by summoning 
defenses and traps 
throughout their lair 
as members of one of 
four distinct hero classes. 




Trendy Entertainment's UDK 



In addition to levying strategic commands, players 
engage in a healthy dose of direct combat while 
upgrading statistics, looting equipment and gaining 
special abilities. Seamless online and local multiplayer 
enable players to cooperate and compete to build the 
strongest heroes and achieve the highest scores. 

The goal of the first release of Dungeon Defense is to 
provide the growing UDK community with open- 
source, open-content examples of ways to implement 
various types of gameplay within Unreal Engine 3. 

"From a development standpoint, working with UDK 
has been like driving a Ferrari," said Jeremy Stieglitz, 
studio head of Trendy Entertainment. 

"UDK enabled us to focus on gameplay design rather 
than technical underpinnings so that Trendy's indie 
team was able to take our idea from paper concept 
to a fully realized demo in just four weeks. Plus, it's a 
huge comfort knowing that by using UDK our content is 
ready for all sorts of Unreal platforms." 

Check out Dungeon Defense in the Project Show-off 
section of the UDK forums {www.udk.com/forums) to 
read blogs about each step of the game's creation, view 
development videos and download code samples. 



EPIC GAMES JOINS KHRONOS GROUP AND DEMOS 
UNREAL ENGINE 3 FOR MOBILE DEVICES 

Epic Games has joined Khronos Group, an industry 
consortium creating open graphical standards, as a 
member of its Board of Promoters. Khronos member- 
ship will enable Epic to provide significant input into 
the development and evolution of key graphics 3D 
standards, such as OpenGL and OpenGL ES, that enable 

our game engine 
technology on an 
increasingly broad 
range of platforms. 

We recently con- 
cluded technology 
demonstrations of 
Unreal Engine 3 on 
iPhone3GS,iPod 
Touch (third-gener- 
ation) and NVIDIA's 
powerful new Teg ra 
2 platform. We are 

very excited about 
powered Dungeon Defense the emergence of 

mobile platforms that are great candidates for Unreal 
Engine 3-powered games and applications. 

"Epic is one of the most respected games technology 
companies on the planet and Khronos is delighted 
to have their participation as we create the APIs that 
enable key gaming engines, such as Unreal Engine 3, 
to tap into the power of 3D GPU acceleration on a wide 
range of platforms," said Neil Trevett, Khronos president 
and vice president of mobile content at NVIDIA. 

"Epic's real-world experience and standing in the in- 
dustry will enable them to bring enormous insight and 
influence to the evolution of the OpenGL and OpenGL 
ES specifications that will benefit the entire industry." 

We joined the board of Khronos to have a seat at the 
table in determining how the major APIs for visually 
compelling mobile graphics will evolve over the next 
few years. Our goal is to ensure that the functionality 
essential to bringing rich experiences to mobile users 
is enabled on both the hardware and software side of 
modern devices and platforms. 




For UE3 licensing inquiries email: 

licensing@epicgames. com 

For Epic job information visit: 
www. epicgames. com/epic Jobs, h tml 
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Epic, Epic Games, the Epic Games logo, Gears of War, Gears of War 2, Unreal, Unreal Development Kit, Unreal Engine, Unreal Technology, Unreal Tournament, the Powered by Unreal Technology logo, and theCircle-U logo are 
trademarks of Epic Games, Inc. in the United States of America and elsewhere. Other brands or product names are the trademarks of theii 
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2) EXPERIENCE FROM PREVIOUS 
GAMES. We had made several TRIALS 
games before, so we knew the basic 
game model was excellent and 
addictive. Some TRIALS 2 players had 
clocked over 1,000 hours of playtime 
in a year. The gameplay is simple, 
but deep— each time you play it, you 
learn something new. We were not 
going to change this in the new game. 

The new physics engine meant 
that we had to rebuild the bike 
control and physics from scratch, 
and that was no easy task. For a long 
time control was way off, making 
the bike unstable and difficult to 
ride. Fortunately we have many 
experienced TRIALS players on the 
team who weren't going to accept 
that. Microsoft then suggested that 
we add easier bikes to address the 
difficulty problems. That was a widely 
accepted idea, but we also knew that 
we first had to make one bike handle 
properly before making variations of 
it, or we would end up tuning each of 
them separately. It took almost six 
months of fine tuning until we felt the 
controls were finally perfect. 

We also aimed for a game with as 
few delays as possible, based on our 
experience with previous titles. TRIALS 
is all about replayability. Players are 
going to mess up and press both the 
restart and return to last checkpoint 
buttons countless times, so we had to 
make them fast to use. We optimized 
the track initialization and reset 
times, and kept the track sizes small 



to further help with this. Additionally, 
we ended up with a design where 
everything was loaded into memory at 
the initial loading, so there would be no 
other loading screens anywhere. This 
required some compromises to the 
texture sizes to make everything fit 
the memory, but the end result is very 
good and very quick. 

3) APPEAL TO BOTH BIT MORE CASUAL 
AND HARDCORE GAMERS. TRIALS 2 had 
been a game for hardcore gamers, 
but with TRIALS HD, we wanted to 
broaden the market. The first thing we 
had to do was to address the initial 
difficulty. We divided the racing tracks 
to five difficulty levels with very easy 
beginner tracks. Then we added new 
beginner bikes which were much more 
stable and easier to use than the bikes 
we ultimately designed the game for. 
General bike control was also a bit 
more forgiving than it was in TRIALS 2. 
These changes alone made the game 
more accessible. 

By adding different medal limits 
to the tracks we could offer targets 
for players with different skill levels. 
Gold limits were set so that even many 
of the more casual gamers had the 
chance to reach a high completion 
ratio. To add some challenge for the 
hardcore, we also added hidden 
platinum medals with really hard 
limits. It was important to hide these 
extra hard medals initially, so that 
people wouldn't be frustrated while 
trying to get the best medal for 



each track before their skill would 
allow them to do it. We revealed the 
platinum medal only after the user had 
passed one extreme track, which we 
considered to be a sign that the player 
had the skill required. 

Skill games were also very 
important in broadening the target 
audience. They are easily accessible, 
and while some of them feel a bit luck- 
based, they actually teach you skills 
required by the main race mode. For 
example, the "outside the ball" mode 
trains your throttle control. Skill games 
are also a good alternative for the 
sometimes brutal race mode. 

4) EDITOR. The editor used in the 
released game is exactly the same as 
the one we used to make the official 
tracks. Originally we had plans to add 
keyboard and mouse support and 
some special features to the editor, but 
we didn't get them to work properly 
right away. Instead, as track designers 
started getting used to making tracks 
with their game pads, they started 
to feel like we wouldn't need any 
additional tools if we just polished 
the editor pad usage. This was a great 
decision, which benefited both us and 
the players! Yes, it's true! All our tracks 
are made using game pads on TRIALS 
HD test builds running on the test kits. 
Because we were using the same tools 
as the end user we had to make them 
both powerful and easy to use. We also 
ended up testing and honingthe editor 
into something much better than it 



might have been if the development 
editor had been completely separate, 
and even more so if it had been an 
external PC tool. 

5) DEMO AND MARKETING. We 
acknowledged early on that the demo 
was going to be an important part 
of the game, perhaps even the most 
important when considering sales 
figures. We had also learned some 
lessons from the TRIALS 2 demo, one 
of which was that a demo should not 
contain tracks that are too hard, and 
that it should have enough content to 
introduce the game, but to also keep 
players hungry. With this in mind we 
included three very good-looking, fun, 
and moderately challenging tracks. We 
also added the quick track and bike 
unlock mechanisms which were differ- 
ent from the ones in the actual game. 
Unlocking new bikes quickly was 
crucial, as the first beginner bikes are 
dumbed-down and might give players 
the impression the game was boring. 

Being part of the Summer of 
Arcade campaign was also a big thing 
for us. This, in itself, secured high 
name recognition for the game a 
good few months before the release. 
While many people knew the name, 
they didn't know what the game was 
all about. But when they tested the 
demo on release day, many were 
instantly hooked. 

One interesting nuance that 
provided extra support was 
releasingthe game fully 
playable on the test network 
almost two months before 
release, while we were 
finishing the game for 
certification. This created 
buzzamongthe press 
and everyone who 
had access to the test 
network. While TRIALS HD 
was not that well known 
by the general public on 
launch day, the press had 
already played the game 
for some time and were quite 
deep into the game once they 
started reviewing it. TRIALS is 
a game where you need to 
put in some time before you 
master the controls and see 
the full depth of the game, 
so this was a good thing. 

CONTINUED ON PAGE 18 i 
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WHAT WENT WRONG 
1) TIGHT SCHEDULE WITH LOTS OF 
UNKNOWN FACTORS. The schedule 
and milestones of TRIALS HD were set 
in preproduction before the initial 
design was fully done. Duringthe 
design phase, we were more focused 
on designing a bigger, more excellent 
game instead of aggressively scoping 
down features to match the schedule. 
There were also some uncertainties 
about the time it would take us to learn 
the new platform, as well as the new 
physics engine. We looked at both the 
schedule and the design and it looked 
pretty tight, but we were confident 
we could pull it off. We also knew that 
there was a possibility of being in the 
next Summer of Arcade promotion if 
we succeeded in making a good game 
and finished it in time. 

Of course, not everything went 
according to that premature, tight 
schedule. We spent a bit more time 
than we expected porting all our tools 
to work on the Xbox 360, which set 
the atmosphere for the whole project. 
While the initial port of the physics 
engine was done fairly quickly, the 
performance wasn't as good as we 
had hoped. It took a fair amount of 
additional work to optimize it to use 
the vector units and make it run at a 
decent speed. Fine-tuningthe bike 
handling with the new physics engine 
also took more time than expected. 

Then there were the menus. We 
chose a free menu engine, which 
looked good initially, but ended up 
making a quite a lot of unexpected 
work for our main menu coder. We 
had to write heavy menu handling 
logic and a cache system which 
required code hooks for each menu 
screen. We also had to battle with 
some mysterious quirks of the engine 
and had to invent workarounds 
around them. Not only were the 
menus a lot of work initially, we also 
had to totally redo them around half- 
way into the project after some good 
feedback and new ideas. In the end, 
we felt that had we used some more 
established commercial menu engine 
or even one made in-house, we might 
have saved some time and money. 
We should have spent more time in 
the early phase of the project investi- 
gating the free engine more heavily. 

Our graphics engine renderer also 
required a lot of experimentation. Our 
older PC graphics technology (from 



TRIALS 2) used too much graphics 
memory and bandwidth to work directly 
on a game console. During TRIALS HD's 
preproduction we switched out our 
old, over-featured deferred renderer 
for a new, ultra slim and efficient light 
indexed deferred renderer (LiDR). 
However, when the content design 
was complete, it was apparent that the 
stencil shadow-based lighting system 
ported directly from our old engine had 
too many content design problems to 
overcome. So we created a new shadow 
map based system, with fancy ESM 
filtering, CSM sunlight, and support for 
transparent shadow casters. 

The new LiDR renderer didn't 
perform well with the new shadowing 
system, so we fully re-factored the 
renderer again. This time the renderer 
became a standard forward renderer. 
The standard forward renderer lasted 
until the final stages of the project. At 
the last performance fine tuning stage 



we noticed that the forward renderer 
was too sluggish in levels that had 
high light counts. So a new slim 
platform optimized deferred renderer 
was created. After fine tuning it for a 
month or so, it performed really well 
in all levels, allowing us to keep the 
locked 60 fps rendering we dreamed 
of. In the end, all this experimenting 
and prototyping was necessary to 
learn the new platform, and while it 
might have taken more time than 
expected, we now have much broader 
knowledge for our future projects. 

2) SECONDARY GAME MODES. Original 
plans for TRIALS HD included smaller 
freestyle and crash game modes 
with 15 tracks each. Skill games were 
not in the original plan. Crash mode 
was originally planned to be a fun, 
BURNOUT-style crashing mini game 
aimed toward a more casual target 
audience. Freestyle mode was meant 



to be a cool trick mode which would 
combine the flip and wheelie modes of 
TRIALS 2 into one mode, utilizing some 
scoring and combo ideas, a bit like the 
ones from TONY HAWK games. 

Needless to say, both of these 
game modes had their fair share 
of problems. While we did like the 
freestyle mode, we acknowledged 
that it was very hard, and had an 
unfinished and unbalanced scoring 
system which was full of potential 
exploit cases. Around halfway 
through the project it started to look 
like this mode might not make the 
final game, as fine tuning the scoring 
would take a lot of work and generally 
the difficulty was not great for the 
casual audience. 

Crash mode was a different 
case. This was the mode that was 
originally thought to be an important 
element in bringing the game to casual 
audiences, and we thought it'd be a 
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PUBLISHER Microsoft 
DEVELOPER RedLynx 
NUMBER OF DEVELOPERS 10 

LENGTH OF DEVELOPMENT 

12 months 

RELEASE DATE August 12th, 2009 
LINES OF CODE 

Red Lynx Theatre Engine: 520,000 
plus external libraries. 
Trials HD Specific: 150,000 

SOFTWARE 

RedLynx Theatre Engine (internal), 
Bullet Physics, Visual Studio 2005 and 
2008, Photoshop, Lightwave 

PLATFORM Xbox Live Arcade 

ADDITIONAL DATA 

1 baby boy, named Santeri, was born. 
1 wrestling mat was bought by 
company. 

900 energy drinks consumed by 
programmers. At least 2,000 liters of 
coffee drunk. 

1 wrestling match where Ville beat Antti. 



big selling point. Still, there was also 
some skepticism about how we could 
make it work really well: Our core 
gameplay is limited to a 2D plane, 
and the only way to give the users a 
choice of where to crash was to build 
the track vertically on multiple levels 
and add ramps to jump between them. 
As we tested different designs for 
this mode, there just weren't enough 
different routes on the track, so crash 
outcomes were quite limited. On top 
of that, some of the jumps between 
different platforms were pretty difficult. 
The added difficulty started to take the 
game further away from the casual 
target group. But there was an even 
bigger issue— the mode just wasn't fun. 
Crashing into objects didn't work as well 
as we would have liked, often resulting 
in the object getting stuck in front of 
the bike, and generally the game mode 
just lacked an overall goal. We ended up 
iterating this mode several times with 
different scoring systems, boosters and 
collectible targets, but nothing seemed 
to work well enough to support a 15 
track game mode. 

However, all this iteration to build 
the crash mode finally paid off in 
an unexpected way. Having tested 
a number of things, we learned that 
there were individual tricks, designs, 
and gameplay elements of the crash 
and freestyle modes that actually 
were fun. When we then started 
looking at a potential new mode with 
fresh eyes, instead of this one big 
crash mode, we took some of the fun 
small parts, created some smaller 
gameplay ideas, and finally ended up 
with our skill mode. 

3) TRACK SHARING. Editor and track 
sharing was an interesting element 
of TRIALS HD. The main features of the 
game were racing, skill games, and 
leaderboards. But level creation and 
sharing also fit the game really well. 
Thinking back, perhaps this should 
have received more attention early on. 

As the schedule was looking tight 
originally, and there was already a lot 
to work on, we designed track sharing 
to be as simple as possible, and in the 
end we came up with a good solution. 
This solution also had the benefit of 
being able to share tracks even when 
the track sharer wasn't online. We 
considered this to be a good feature. 

But oursimple, quickly-done 
solution wasn't made completely by 



the book, and we had to implement 
some restrictions to avoid potential 
issues. Thinking back, it's easy to say 
that we waited too long to implement 
our sharing system. There are a lot 
of things to take into account with 
sharing, and every one of them has 
to be done carefully. With the time 
and resources available the sharing 
system built was a good one. But 
it also taught us that if we want 
bigger and more developed sharing 
systems, we can't underestimate the 
time and resources required. 

4) PROGRAMMERS WERE ASSIGNED 
TOO SPECIFICALLY. At the start of the 
project each of our four programmers 
was assigned a few specific tasks. 
When dealing with a new platform, 
there's always a learning process, and 
we thought that if we had each pro- 
grammer concentrate on a few specific 
areas. The learning overhead would 

be smaller and each of them would 
perform faster in the area they were 
familiar with. 

This mindset led to some 
problems during development. There 
were some sick leaves, and the work 
effort across different areas was not 
completely even. This meant that it 
was hard for them to back each other 
up, since everyone had a different 
field of expertise. 

We did notice this problem fairly 
early, and tried to implement a backup 
system where each programmer 
would be at least partly backed up by 
another. This did not help the situation 
as much as we would have liked, as 
two of the busiest programmers ended 
up backing each other. In some other 
projects, we had already been using 
our own "common-sense-scrum" 
project management model (good 
parts from scrum adapted and used 
effectively in smaller scale projects). 
In that system, it was customary for 
programmers to work as a team and 
share tasks with each other. With the 
high burden put on some TRIALS HD 
programmers, we had the additional 
motivation to start applying the same 
flexible common-sense-scrum to all 
our projects— which seems to have 
been a very good decision. 

5) DIFFICULTY CURVE. While the initial 
difficulty level of the game was well- 
suited to casual gamers, the game 
partly lacks proper means to teach 



advanced bike control techniques 
to target audiences. Only about 50 
percent of players could pass the 
hard tracks, and less than 20 percent 
had success in the extreme tracks. 
A common comment about the 
game was that while it is fun, it gets 
brutally hard too quickly. This is a bit 
unfortunate, as the game only reaches 
its full potential once the tracks 
become more technical and the players 
start to understand and utilize some 
advanced bike controlling tricks. The 
harder part of the game is the best and 
most rewarding for the more advanced 
players, and we wanted to maintain this 
difficulty level, but we definitely should 
have included ways to gradually teach 
users all the tricks required. 

We knew about this issue while 
developing the game. TRIALS 2 had the 
reputation of being extremely difficult. 
We had already adjusted the base 
difficulty with easier levels, beginner 
bikes, skill games, and generally more 
forgiving bike control, but we still 
allowed players to enter the difficult 
tracks before they had learned the 
required skills. We tried to partially 
solve this issue by locking the harder 
difficulties until the player had passed 
three levels from an easier difficulty, 
but this was way too little. It might 
have been better to require three gold 
medals instead, but then players might 
have complained that they could not 
play the game they bought because 
of level locking being too strict. We 
also tried to add tutorial levels, but 
they proved to be fartoo simple and 
inadequate for all the skills required. 

We actually had several ideas for 
better tutorials including videos with 
narrative help texts, and example 
replays for each checkpoint, but 
in the end, we went with a simple 
tutorial. This was partly because of 
time constraints and partly because 
in this age of "easy" games, many 
players want to skip the tutorials if 
they become too heavy. While simple 
tutorials are usually better for new 
players when they are learningthe 
game, it's clear that more advanced 
tutorials would have helped. 

KEEP YOUR HELMETS 
FASTENED! 

» TRIALS HD has been a huge 
success for us as a company, and for 
the team that made the game with 
huge dedication. TRIALS HD is a great 



game, with great sales, great reviews, 
and most of all, lots of buzz, approval, 
and highly welcomed discussion 
between us and the gamers. Having 
developed games for quite a long 
time and finally getting this sort of 
recognition and success make us 
both proud and humble. We know that 
this type of success case is rare— 
you have to work hard, and have 
some serious luck. At the same time, 
we learned a lot from this success, 
and hope to apply what we've learned 
to future projects. 



J 0 R M A S A I N I 0 is the project 
manager and network programmer, 
SEBASTIAN AALT0 N E N is the lead 
game programmer and 3D engine guy, 
ANTTI I LV E S S U 0 is the creative 
director and lead designer, and T E R 0 
VI RTALA is the ceo at RedLynx. 
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STATE OF DEVELOPMENT 2009 

ASURVEYOFOUR READERS AND CONFERENCE ATTENDEES 

Every year, Game Developer Research, a sister division to Game Developer magazine, conducts an extensive survey exploring all 
aspects of development. Game Developer subscribers, registered Gamasutra users, and Game Developers Conference attendees 
are asked dozens of questions about themselves, their studios, their games, and the products and tools they use. 

The State of Game Development survey offers a snapshot of our readership and conference attendees, summing up where 
developers live, what's important to them in making games, and what they plan to do in the coming year. For the first time, we 
are publishing select details from the survey in these pages concurrently with its full release through Game Developer Research 
(www.gamedevresearch.com). 



THE STUDIOS 

» According to our research, most 
of our respondents still work at fairly 
small companies, with 61 percent 
reporting an employee count of 50 
or fewer, 19 percent reporting a total 
between 51 and 500 employees, 
and 20 percent reporting companies 
with more than 500 employees. 

Those figures may suggest an 
increase in the relative number 
of developers at small studios. 
The proportion of responding 
developers at companies of 50 or 
fewer has risen ? percent since last 
year's survey, while the proportion 
employed by companies of 500 
employees or more has gone 
down 2 percent. 

There are various factors that 
may explain this movement. In the 
past year, widely-reported economic 
turmoil has led many large publishers 
to institute sweeping job cuts and, in 
many cases, close internal studios 
altogether. As a result, 2009 has 
seen a wealth of newly-formed 
independent game studios, not 
to mention the many individual 
developers looking to take advantage 
of emerging business models for 
small-scale games— a trend partially 
reflected in the employee statistics 
shown in Figure 1. 

When it comes to core business 
models, in accordance with those 
figures, the largest proportion 
(30 percent) of our respondents 
reported working for independent 
third-party developers making 
console and/or PC games for 
retail, although nearly as many 
(28 percent) said they work for 
publisher-owned retail-oriented 



studios. Only 5 percent reported 
working on the publishing side itself. 

Perhaps surprisingly, fully 21 
percent of respondents said their 
studios— either independent or 
publisher-owned— are focused on 
digital distribution for any platform, 
rather than retail. Another 15 
percent— again, either independent 
or publisher-owned— are focused 
on browser-based or social games. 
Those two statistics demonstrate 
the already significant impact of 
direct-to-consumer technologies 
and business models, even as they 
are still in their formative stages 
(see Figure 2). 

And, reflecting another important 
trend in the game industry 
(explored in greater detail in Gome 
Developer Research's separate 2009 
Outsourcing Report], significantly 
more respondents this year said 
their companies focus on contracted 
or outsourced development services. 
Of respondents whose companies 
focus on development, last year 
21 percent said their studios see 
contracted work as a primary line of 
business, while this year that figure 
jumped to 3? percent. 

THE PLATFORMS 

» We asked developers to tell us 
what game platforms they've been 
targeting with their most recent 
games. The answers weren't mutually 
exclusive, so within a certain platform 
category, developers could choose 
any number of specific choices. 

Overall, the highest proportion 
(72 percent) said they are targeting 
a PC platform; crucially, that group 
includes not only traditional 



video games but also web-based, 
social, and PC casual games. The 
next largest group (41 percent) 
is targeting home consoles. Only 
about 15 percent of developers are 
working on handheld consoles like 
the Nintendo DSorPSP. 

While most of those platform 
figures were in the same 
neighborhood as they were a year ago, 
about a quarter of our respondents 
are working on games for mobile 
platforms. That's more than double 
last year's figure of only 12 percent, 
a proportion that has been boosted 
by the huge growth in popularity of 
the iPhone platform. Nearly three 
quarters of developers working on 
mobile or handheld platforms said 
they're working on iPhone titles— well 
overtwice as many as are developing 
for Nintendo DS or PSP, and more than 
six times as many as are targeting 
traditional mobile platforms like J2ME 
and BREW. 

When it comes to the major home 
consoles, Xbox 360 was the larger 
choice, with 69 percent of console 
developers targeting that platform, 
as compared to 61 percent for 
PlayStation 3. The gap between the 
two has tightened somewhat from 
last year, however, shrinking from a 
15 percent delta to only 8 percent. 

Wii, meanwhile, has seen a 
dramatic drop in support from our 
respondents, from 42 percent to 30 
percent, perhaps reflecting some 
analysts' claims that the Wii market is 
softening. Meanwhile, impressively, 
legacy support for the PlayStation 
2 holds steady at 15 percent (see 
Figures 3,4, and 5). 



WHAT MATTERS 

» Developers are opinionated 
people, and a choice made early in 
development can have significant 
ramifications on the entire project. 
So in addition to inquiring about the 
platforms being targeted in their 
latest games, we asked developers 
to choose the three criteria that 
mattered most in their decision to 
pursue those platforms. 

The most important factor? 
In a world of complex, expensive 
game creation, more developers (45 
percent) cited ease of development 
as the top criteria than any other 
consideration, closely followed by 
the platform's market penetration 
(41 percent). 

Just under a quarter of developers 
said the publisher's decision was 
the most important factor, which 
may suggest that in many cases, 
publishers and developers are already 
on the same page when it comes to 
platform opinions. And even fewer said 
the hardware's potential performance 
was the most important. 

Other important considerations 
included team members' existing 
skill sets, portability of code to a 
given platform, and the acquisition 
costs of development kits and mate- 
rials. Respondent-supplied "Other" 
choices highlighted factors like 
the platform's uptake among aging 
gamers, its success ratio with indie 
games, and its traditional strength 
with a particular engine solution 
(see Figure 6). 

UNDER THE HOOD 

» Building games based on in- 
house engines is still the norm in 
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FIGURE 1: EMPLOYEES 2009 


2008 


1-50 61% 


54% 


51-200 14% 


17% 


201-500 5% 


7% 


501+ 20% 


22% 


FIGURE 2: CORE BUSINESS MODEL 

% of Studios 


Third-party retail 


30% 


Publisher-owned retail 


28% 


Digital-oriented 


21% 


Browser-based/social 


15% 


Publishing 


5% 


FIGURE 3: PLATFORM CATEGORY 

% of All Developers 


PC/Mac/Browser/Social 


72% 


Home Console 


41% 


Mobile Phone 


26% 


Handheld Console 


15% 


FIGURE 4: HOME CONSOLE 

% of Console Developers 




Xbox 360 


69% 


PlayStation 3 


61% 


Wii 


30% 



TOP (left to right): FOREIGN LEGION: BUCKETS OF BLOOD (Unity 3D), 
Borderlands (Unreal Engine), Penny Arcade Adventures (Torque), 
Half-Life 2 (Source), Far Cry (CryEngine). BOTTOM (left to right): 
Freedom Force (Gamebryo), Kabus 22 (Gamestudio), Doom 3 (id 
Tech), Planet 51 Online (Vision), PuzzleQuest (Vicious). 

FIGURE 6: CRITERIA 

% of Developers 



PlayStation 2 15% 
FIGURE 5: HANDHELD/MOBILE 

% of Portable Developers 



Ease of Development 




45% 


Market Penetration 




41% 


Team's Skill Set 




33% 


Cost of Development Kits 




28% 


Publisher Decision 




23% 


Portability of Code 




23% 


Platform Performance 




21% 


Technical Support 




10% 


Developer Relations Program 




8% 


Other 
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FIGURE ?: GAME ENGINE USAGE 

2009 


2008 


Commercial 


36% 


29% 


In-House 


64% 


71% 



FIGURE 8: TOP 10 COMMERCIAL 
ENGINES (ANY VERSION) 

% of Developers 



Unity 3D 


35% 


Unreal Engine 


30% 


Torque Game Engine 


19% 


Source 


13% 



CryEngine 



11% 



iPhone/iPod Touch 


74% 


Gamebryo 


8% 


Nintendo DS 


31% 


Gamestudio 


7% 


Android 


27% 


id Tech 


5% 


PSP 


23% 


Vision Engine 


3% 


Other 


11% 


Vicious Engine 


3% 



our industry, but that may change over 
time. The number of respondents who 
told us they use commercial game 
engines in development rose noticeably 
this year, from 29 percent to 36 percent 
(see Figure ?}. 

We also asked that group of 
developers what engines they use, 
and the results were incredible on a 
year-on-year basis: the Unity 3D engine, 
which has gained renown for its ease 
of use, lightweight browser gaming 
plug-in, and iPhone support, shot up 
in support this year to become the 
most-used engine. About 35 percent of 
commercial engine-using developers in 
our survey said they are using Unity on 
a project, up from only about 4 percent 
the previous year. 

Epic's Unreal Engine 3, the traditional 
engine champ, held its share at about 30 
percent. Other commonly-cited choices 
were GarageGames' Torque suite, 
Valve's Source, CryTek's CryEngine, and 
Emergent's Gamebryo. 

Readers should bear in mind that 
engine choices were not mutually 
exclusive, so it's likely that many of those 
Unity users are tooling with the engine in 
their spare time, particularly since creator 
Unity Technologies made a version freely 
downloadable last October. But any way 
you slice it, it's a lot of developers gaining 
proficiency and familiarity with the tool 
set (see Figure 8). 

WANT MORE? 

» The full State of Gome Development 
2009-2010 Survey includes dozens more 
data points about the preferred software, 
hardware, and tools of game developers, 
as well as game genre and sector 
statistics, geographical breakdowns, 
budgetary information for the past year, 
and upcoming product purchase intent. 

It was conducted with a sample 
size of 814 users of Gome Developer 
magazine, Gamasutra, and members of 
the Game Developers Conference, and 
can be projected to the overall game 
development community with a margin 
of error of plus or minus 3.4 percent at 
a 95 percent confidence level. 

Those complete results are 
available as a 100-page report from 
Game Developer Research (www. 
gamedevresesarch.com) for $2,495, 
alongside numerous other reports 
delving into the key facts and 
trends that define the modern game 
development industry. ($> 
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OTHER PROJECT I'VE BEEN A PART OF OR HEARD 

eep going. They couldn't get enough. That is really saying 



MAKING BORDERLANDS WAS A BOWL FULL 

about. At the end of the project, the whole te o o o u o 

something powerful, and I think it shows in the final product. We are making a major effort to learn lessons from 
our development of the game in orderto keep the spirit of the project alive throughout everything we do. Gearbox's 
pillars are Creativity, Happiness, and Success. We hit every one of those goals with this project. I'm proud to have 
been a part of the team that made it, and I know that every other member of the team feels the same way. 

We wrangled ourway through and made a kick ass game that's making tons of people happy and making tons 
of money, of which everyone at Gearbox gets a piece. The incentive of back-end participation is really a motivating 
factor in building momentum and passion. Money isn't enough to create this success, though. Love for the craft and 
a desire to focus on fun was the ultimate driver in keeping us all going. 

All the core features were implemented for the first prototype in 2006. In creating a hybrid shooter + RPG, we made 
a conscious decision to play to our strengths. As a studio known for our work in shooters, and high expectations for 
combat, it was important to get shooting to feel good as a core mechanic early on. The team was fresh off the HALO 
PC port, where they were inspired to borrow the data-driven concepts HALO provides designers and bring those to an 
Unreal Engine 3 game with our own original IP. It was a long-standing dream among several people at Gearbox to try 
blending the loot and leveling motivators from RPGs with a shooter. Following the first BROTHERS IN ARMS game, a small 
concept team set out to establish how we might approach this promise of a familiar RPG loot loop and leverage our 
shooter expertise. The premise was easily understood and core features were implemented early, but with the devil 
hiding in the details, one of our biggest problems was that we didn't know what we didn't know ... yet. 
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ART STYLE AND "THE CHANGE" 

» At the beginning of the project in the middle 
of 2005, we went through an ideation phase and 
invited people across the studio to participate. In 
the earliest versions of the game, the focus was 
on blending a hip western meets sci-fi narrative 
with the theme of bounty hunting mercenaries 
seeking fame and fortune on a deadly alien 
planet full of warring militaristic clans. The art 
style in particularwas something that many 
people had an opinion about. Art reference boards 
were created for each proposed style in addition 
to a forum that polled people on their opinions. We 
ended up deciding that a retro style, embodied 
in a "maschinen krieger" (good search topic) 
aesthetic, would be best for the feel of the game. 

The team continued to explore what the 
right attitude and feel of the game should be 
throughout development. The art team was 
influenced to incorporate plausible elements 
into the style to ground the game in realism, 
although from other vectors, the project was 
becoming creatively less realistic. This led to a 
pivotal realization in late 2008 that the art style 
and game design had diverged; the fun we were 
finding as the attitude, humor, and fantastical 
character skill system evolved had moved too 
far away from what was represented in the art 
style to continue to fit well together. We were 
very happy with the direction that the game 
systems had gone, but now we needed an art 
style to match. 

The notion of a graphic novel art style was 
kicked around in discussions, and had come up 
as something that would be cool to try at some 
point in the future with one of our games, but 
there was no practical way to experiment until 



a need presented itself. At some point in the 
project, we were looking for an answer to the 
issue of how gameplay and style had diverged. 
Our "creative czar", Brian Martel, decided to 
investigate what it would take to realize this 
style in BORDERLANDS. The result became known 
internally as "The Change." 

WHAT WENT RIGHT 
1) CODE STABILITY. Our code department is an 
example of leadership making all the difference. 
The game's technical director, Steven Jones, 
and lead engineer, Jimmy Sieben, made sure 
that code would always work cooperatively 
with design to help implement reliable features 
that did exactly what was specified, so the 
team could always trust our code base to work: 
Everyone could get their jobs done with no 
noticeable downtime. 

The first thing new members of the team 
heard about was build stability. Our build was 
never down. There was a lot of pressure to 
maintain stability, and there was a general 
philosophy of incremental improvements rather 
than large changes. Further, our engineering leads 
were constantly looking into improving our build 
times. We went from day long builds on our last 
BROTHERS IN ARMS title to four hour complete builds 
and 30 minute updates for content developers. 
Our lead engineer would manually configure 
and build the game to ensure all parts were 
integrated correctly. We worked hand in hand 
with HP to design a new build server that would 
help us be even more efficient. That enabled our 
OA department to have a full build at the end of 
each day to perform Build Verification Tests the 
next morning and give full reports the next day. 



We have a very efficient process for merging code 
from Epic, and this proved invaluable throughout 
BORDERLANDS' development. 

2) DECISION MAKING AT THE EDGE. Hierarchy 
was modified when necessary to find the most 
optimal path to implementation. After The 
Change, the senior producer pulled together 
our department leads and established a pact 
that they would share a mindset that the game 
would ship on time and that people who have to 
live with the decisions that were made should be 
directly involved in making them. 

We have a culture where people move 
into roles where they can be most effective 
depending on what needs to get done. For 
example, someone might be a director on one 
project and leading an aspect of development 
(like Ul) on the next; at Gearbox, this is a vital 
aspect of how we organize ourselves to ship and 
ensure quality in critical areas. Adaptability in 
organization based on the mission at hand is a 
cultural trait that is rare in the industry, and we 
practice this with intent. 

Our experience has shown us that a surefire 
way for a feature or decision to fail is to push it 
on an individual who wasn't involved in making 
it and doesn't have ownership of it. The outcome 
will never be as good as when the implementer 
helps create the specification for a task and 
understands the driving goals behind the need for 
it. While this may seem like an obvious assertion 
on the surface, it took us some time to recognize 
the universal truth of it. Before The Change, the 
team was working from a legacy structure of 
hierarchical decision-making in both design and 
production. The point at which we decided to 
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commit ourselves to shipping in 2009 and looked 
at what it would take to realize that vision, we 
also decided it would only be possible by giving 
more decision making power to each member of 
the team. 

We started the project with a hierarchical 
model of a lead that has sole decision making 
power, but that was actually at odds with the 
company's fundamental desire to flatten team 
structures whenever possible. So in the process 
of reconciling our goals with our schedule, we 
arrived at a more natural state of organization. 
We simply allowed people to focus on quality 
and brought out performance by removing 
barriers to personal investment. 

3) SKILL SYSTEM. The Skill System is an example 
of where the mindset of distributing design 
authority in orderto ship on time enabled 



and the Ul design lead to implement his ideas. It 
was one of the first examples of a team member 
being given permission to work outside the 
previous hierarchical structure. In that week, 
he revamped the entire system. Working with 
another designer who was very familiar with the 
existing system and able to use the data-driven 
designer tools, the pair came up with an entirely 
new set of skills, arriving at skills trees that were 
about 50 percent new and 50 percent modified 
existing skills. For a game with four characters 
and 22 skills per character, that's a lot to concept, 
implement and polish! 

In an inhuman feat of development prowess, 
Ul and code were able to turn around a whole 
new screen for the proposed system in less than 
a week, soup to nuts. With another three to four 
weeks of polish, the system was done. In the 
previous three years of development, we hadn't 




immediate improvements. One of our more 
senior game design leads— who is also a veteran 
artist— was brought onto the team during The 
Change and given the monumental task of 
redesigningthe system as quickly as possible. 
In our play tests in early 2009, we were getting 
feedback from Truth (our independent team that 
kept us in touch with what players wanted) that 
players didn't understand how skills worked or 
how they improved the overall experience. It 
was unclear to players how leveling worked, how 
skill points were assigned, how skills tied in with 
character differentiation, and the value of using 
skills as part of the combat loop. The system 
was especially inaccessible to our primary 
shooter audience, who did not want to break 
out of shootingto use skills. Since a fun skill 
system and its relationship to character leveling 
is fundamental to how we designed our game to 
play, this was a major problem— one that we were 
still encountering very late in development. 

The designer assigned to this task reviewed 
the whole system in a week and was given the 
responsibility and authority to make decisions 
and direct the gameplay coders, other designers, 



been able to do that. In this case, the right person 
in the right job with the authority he needed made 
all the difference. With this example of success 
in distributing design responsibility, we then had 
the confidence to distribute full responsibility for 
other systems and tasks. 

4) KIT BASHING MENTALITY. We evolved a highly 
efficient process for making art, especially for 
environments. Before The Change, our art director 
had the equivalent of at least five full-time jobs; 
complete internal and external art direction, 
scheduling oversight for all aspects of art, creating 
style guidelines, establishing technical specs and 
standards, personally making art to set a standard 
for the team, and creating effects items like 
skyboxes. That is too much for one person to take 
personal responsibility for on a triple-A project that 
needs to scale up for full production. 

During The Change, the art director, who is 
also one of our strongest artists, was inspired and 
wanted to focus on working between level design 
and the art team to help execute the new style, 
and was absorbed into the newly-formed Visual 
Design Team as a senior artist. We then divided up 



what was one art director's job into art director, 
art team lead (who was also directly responsible 
for all effects art and technical art staff), internal 
art producer, outsource art producer, environment 
art (Visual Design Team) lead, and outsource art 
lead. By aligning people with their passions, we 
got the most out of them, like rearranging legos in 
interesting ways to get your desired end result. 

Our newly formed Visual Design Team, 
composed of visually-oriented level designers 
and a couple of senior artists, took on the 
simultaneous challenge of defining howthe new 
art style would work technically and also how it 
would be aesthetically propagated throughout 
the game. The answer was to make heavy use 
of kit bashing. Kit bashing is a technique Epic's 
level designers have used and subsequently 
promoted as a good use of the Unreal Engine to 
reuse assets by rotating, scaling and combining 
them in novel ways to get whatever your desired 
visual outcome is. 

Fy restone was the big test for our newly- 
proposed art style. The newly established Visual 
Design Team set out to show how the style would 
work in a small vignette; something large enough 
to run around in, with some variety, that could 
be built out of a small set of props in the new 
style; they built a pipe, corrugated tin, a barrel, a 
tire, two grey girders, a piece of terrain art and a 
few other pieces. Out of this set, they kit bashed 
the entire first version of Fyrestone. We didn't 
have the outline tech in yet, but the outsource 
art lead— who came on to BORDERLANDS having 
been the art director on another project— recalled 
a technique used in a popular old QUAKE mod to 
double meshes and reverse faces to produce 
the desired result. Even the style itself was kit 
bashed to prove the concept! 

5) THE NEW ART STYLE. Not long after the 
Fyrestone test was completed, our CEO Randy 
Pitchford took this example to 2Kto pitch The 
Change. This was a risky prospect, and we had no 
idea how 2K would respond. Internally, we knew 
what kind of risk this posed to production. There 
were a lot of influential people, Randy at the top 
of that list, who thought it was probably a very 
bad idea to open the door to that level of change 
so late in the project. But everyone who saw it 
recognized its potential, and almost everyone 
had a strongly positive reaction to it, especially 
when they saw it working in game and could 
navigate a space with the style implemented. 
Fyrestone served exactly that purpose. When 
Randy made the trip to 2K in San Francisco to 
pitch it, they decided to make the bet on it with us 
and embrace the new style. That helped cement 
our productive relationship with them, and was a 
great catalyst to get us to focus together on how 
to mobilize to ship later that year. 

With the new art style, everything started to 
fit together. We had art that matched the evolving 



attitude of the game. It was now fine for players to jump high up in the air, for enemies to take varying 
amounts of damage based on level, for missions objectives to be zany, for psycho midgets to run at 
you, for brains to pop out of heads intact and fall on the ground, and for a wisecracking unicyclebot to 
show up in the game as your guide. The Visual Design Team described it as "ill-mannered whimsy" and 
the project's director, Matt Armstrong, promoted the notion that our attitude should take inspiration 
from Paul Verhoeven, director ofStarship Troopers and RoboCop— movies where over the top violence 
takes on its own brand of dark humor. It was now okay for things in the world to be humorous, whereas 
with the previous realistic style, the team was shooting for designs that played as "serious business." 
The new feel was something that the entire content team could get behind. Productivity shot through 
the roof. We got into a magical cycle of art inspiring design inspiring art. 

The new style brought with it an added, very practical benefit— the process for creating assets 
could be clearly specified and a state of completion could be articulated and evaluated by the art 
leads. When we were going for a more realistic style, very often it was unclear if assets were done. 
With the new style, there was no doubt. There was also room for iterating efficiency and quality 
within the new style. We had one particular member of the art team with a background in comic 
book art who set the benchmark for quality that the rest of the team constantly shot for; and just 
as they were hitting it, he leveled up the quality of his work with new techniques. For example, in 
experimenting with being more efficient and increasing texture quality, he showed that "color up" is 
better than "ink down" for our style— a very different way of approaching art than game artists are 
used to. In your typical next-gen art workflow, artists bake normals and AO, then use those maps as 
a guide to color in the texture. In our new style, most assets don't need a normal map because we 
ink in the details— similar to graphic novel illustration. Fortunately, we had expertise on the team 
to help us understand the best way to execute and scale into full production. A constant process of 
improvement began, and it included all of our artists, our very small number of trusted outsourcing 
partners, and our art directors. This was a great art team motivator. 

WHAT WENT WRONG 

1) MEMORY PART I: MYSTERY MEMORY. Like most console games, as we approached the end of 
production we had to get a really good grasp on our memory use. The first thing you do is audit the 
memory you're using, so you know what systems are responsible for allocating which gobs of RAM. 
The memory that hadn't been identified as being used by a particular system was simply called 
"mystery memory." 

Without a clearway to diagnose memory problems and assign responsibility, content creators 
(especially more junior ones) don't tend to be very proactive about investigating and fixing their own 
work, because there's no direct connection between their work and the state of the game. It takes 
some advanced knowledge of how the engine works to avoid memory issues, and this kind of mystery 
can be a crutch for plausible deniability, which are two good reasons we look for a veteran mindset in 
even our most junior staff. Unreal Engine is very good at many things, but one area where we have to 
build our own tools is in investigating memory. 

It's hard to fix something when you don't know it's a problem— this is one reason why strict asset 
standards in development are so crucial. It's also hard to justify taking time to 
investigate your work when you have a mountain of new work that has to 
be done in a short period of time. Fortunately we had a very seasoned 
art team lead who is an experienced technical and effects artist. He 
worked with our technical artists to make certain we investigated 
possible memory and performance issues based on the evolving needs 
of the game. Together the technical artists had healthy debates about 
our moving memory targets. This lead informed everyone involved in the 
art asset pipeline about decisions as they were made, and together the 
technical artists made sure everyone understood the impact of asset 
production decisions. 

One of these debates concerned the merits of artists working with 
a high resolution source, which is great for hero assets and producing 
marketing materials, but not great at run time without proper setting 
of LOD biases for mipmapping, or for production efficiency. These 
discussions helped the team focus on what the customer ultimately 
experiences and put in perspective topics like preferences of source 
fidelity and workflow adjustments that needed to be made to 
execute on the new art style. 

Hunting for improvements became a true team effort 
based on technical artists' guidelines, and was influenced by 
discoveries made by programmers. Toward the end of the 
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project as this was becoming increasingly 
important to being able to ship, our technical 
director was able to provide custom memory 
profiling tools that helped break down the 
mystery stack, which was a boon for finding 
improvements. Unfortunately, there is still a lot 
of the game that we don't have detailed memory 
information about. 

2) MEMORY PART II: PLATFORM HEADACHES. 

We had some trouble getting the game to fit 
onto the Xbox 360, but because of the unified 
memory, we were able to get it to fit relatively 
quickly by picking off low-hanging fruit. The Xbox 
360 was certified long before the PlayStation 
3. For the PS3, we struggled and struggled to 
cram the game into the PS3 memory space. Our 
central platform engineer miracle workers did a 
ton of work on this from the platform side (low- 
level tech improvements to move stuff into RSX 
memory, rewrite some of the code to store data 
in more efficient ways, and so on.). This work 
was done while the main team was workingto 
reduce the memory footprint from their end, 
mostly on the content side. 

The PS3 has two things working against 
it: unified memory architecture and very 
large memory page sizes (64K). This meant 
that whenever we would free up memory, we 
didn't actually get that memory back until the 
entire page was free. This caused memory 
fragmentation (like disk fragmentation) to 
skyrocket. Fragmentation is an awful thing. The 
frustrating thing was that we actually got the 
game to fit and run long before we submitted it 
for certification, but as you played the game for 
extended periods, the fragmentation would build 



up to the point where it would eventually run out 
of blocks large enough to allocate something that 
was needed. 

We also had issues with some of our 
middleware platform tools, like our physics 
solution, which was a real memory hog. For 
example, two instances of a mesh would share 
physics data, but if one of those meshes were 
scaled to a different size (like all the rocks in 
BORDERLANDS, for example), then it would duplicate 
the physics memory for that mesh. This particular 
solution was also clearly not written for the PS3, 
because its memory usage patterns caused 
it to fragment quite badly. In the end, we had 
to enable virtual memory for physics memory 
space, which was a hefty last-minute change. 
Another interesting issue was that moving the 
audio memory to RSX memory meant that there 
were times when audio playback would cause bus 
contention with graphics operations (I still have no 
idea how our lead PS3 engineer figured that out, 
but he did.) 

These are not the kinds of core-level 
changes you want to make in the 11th hour. To 
make matters worse, most of these changes 
were riddled with pot holes and speed bumps- 
problems that needed to be resolved. 

3) THE QUEST FOR MISSIONS. After The Change, 
the level design department was given the task 
of designingand implementing all the missions 
for the game. This was no small feat. From 
The Change through to the ship date, the level 
designers understood what would be required; 
with leadership from the level design lead they 
stood together, prepared to put forth amazing 
effort and in the end delivered a completely 



rebuilt game. They had a high level mission 
framework for the game that was finalized at 
the very start of 2009. This framework built 
confidence that they would be able to implement 
objectives without fear that the story— and 
therefore missions— would change, as had been 
a previous concern— and this served to un-stick 
layout of the full game. They put on their mission 
designer hats and began building and testing 
small mission submaps that they would then 
propagate throughout the game. 

The missions system itself evolved from a 
specification that the game design team wrote 
early in the project. Throughout preproduction, 
we were searching for how the game should be 
constructed and were looking for examples of 
fun missions with interesting variety. From 2006 
through the end of 2008, the team was driven by 
short term deadlines for demos, so from a mission 
design perspective we were always constrained 
by what would be appropriate for short, focused 
play experiences that could be developed by a 
small core team in about a six month cycle. As 
we later discovered, BORDERLANDS is a game that 
needs a longer outlook to be truly appreciated. 

Once we had a final narrative structure in 
place, the team was able to think about the big 
picture. That led to lots of new ideas about how 
missions could be fun, which in turn led to many 
support requests to extend the system. By that 
time, the system had gone through several 
revisions but had never been refactored to be 
easy to use for the kinds of missions that were 
taking shape as fun. In the end, there was one 
individual on the team who took it on himself to 
learn the intricacies of the system as it stood, 
and he became the main expert and go-to guy for 
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implementing and debugging missions. 

The system was implemented to make 
use of our data driven interactive object 
system and took shape as a custom scripting 
solution outside of Kismet (Unreal Engine's 
visual scripting interface), which was difficult 
to extend in all the ways our level designers 
requested, especially given how late in 
the project we finally understood what a 
BORDERLANDS mission should be. As we took 
on ship mentality, new feature requests were 
made lower priority. 

On one hand, the constraints made 
designers focus on doing the best with what they 
had, and that was helpful for getting the team 
focused on implementing the kinds of missions 
that the system would allow. On the other hand, 
we had only one person who really understood 
the system inside and out so his workload scaled 
up metrically, and the system's implementation 
made missions hard to debug. 

4) ANALYSIS PARALYSIS AND THE TRUTH. The 

initial core team started the project with very 
high-level goals and understandably blue sky 
thinking. The team decided at that point the 
most efficient tool for documentation and 
communication would be a wiki. That didn't work 
out as the team began to scale. Designs evolved 
faster than the wiki pages that described them, 
and discipline was inconsistent throughout 
the team in terms of keepingthings updated. 
Down the road, this led to difficulty recalling why 
certain decisions had been made, and what was 
on the table for discussion or change versus 
what the team didn't want to revisit until they 
were implemented at a state where they could 
be tested and analyzed. There were times early 
in development when a team member would 
implement things that weren't documented at 
all, which led to confusion about the actual state 
of some features and content. The desired end 
state for some things was not fully articulated, 
and when that combined with disagreements or 
lack of recollection about how they attained their 
present state, there would be meetings where 
many things were discussed but no decisions 
were made. 

There would also be disagreements about 
what the customer would think about the 
item at hand and what the team should do 
next. The project's director had been seeking 
a solution that would involve focus testing to 
bring the customer's perspective into play when 
decisions about iteration were being made. He 
saw a lot of promise in this idea after 2K set up 
a customer play test with an offsite third party 
testing service that provided some eye opening 
results. At the time we made The Change, we 
decided to commit to focus testing specific 
features with representative customers. 

Gearbox's technical director got involved 



and the Truth Team was born. He intended this 
group to speak for the customer and to speak 
through data, not opinions or conjecture. Truth 
turned out to be one of our very best decisions, 
and we are now utilizing the strength of that 
team across all our projects. 

5) WATERFALL DEADLINES IN AN AGILE WORLD. 

We needed a flexible production methodology to 
create a hybrid genre. The team needed parallel 
lanes for innovation across loot drops, leveling, 
mission design, skills development, combat, and 
many other aspects of the game. Deadlines are 
good for getting teams focused, but in the case 
of BORDERLANDS there really wasn't sufficient 
time for reflection and analysis coming out of 
one deadline before we had to do full production 
planning for the next one. From the start of the 
project through the end of 2008, the team was 
making content and iterating systems to be 
shown at internal and external demonstrations, 
and our milestones reflected a desire to measure 
progress toward these goals. As a result, many 
systems were developed in parallel to show 
the intent of the game, but very few were ever 
brought to a polished state. It was like spinning 
plates, giving each one a little attention before 
moving on to the next one. We lacked the 
scheduling flexibility to finish a complete core set 
of features and then build the game around them. 



and game saves, the interconnection of these 
systems required moving across them in iterative 
steps to bring them online together. It's a good 
thingthat Second Wind stuck around because it 
helps create drama for the character, and that is 
very important to crafting an interesting player 
experience. It would have been more efficient if we 
could have finished systems like Second Wind at 
the time they were conceived, which would have 
meant less of the game presented simultaneously 
along the way, but with more robust and solid 
features coming online as each would have been 
completed. That would have been good for morale 
and communicating our intent throughout the 
team and with our partners. 

CROSSING THE BORDER 

» We all love cake. It would be impossible to 
half-bake a cake, change the ingredients, stick 
it back in the oven, and repeat this process until 
that one cake is something you'd be excited to 
present at the cake baking expo to be replicated 
and sold at bakeries internationally. You would 
probably get the opposite of your desired result. 
Many things changed during development of 
BORDERLANDS, and we swapped and shared chef 
hats many times throughout the project. So 
developing BORDERLANDS was not like baking 
one cake. It was like baking lots of multi layered 
wedding cakes, experimenting with different 




As an example, Second Wind was on the 
chopping block from the time it was proposed. 
Second Wind is a time-based game mechanic 
that gives players a chance to get up from a 
knockdown state as they are dying by killing an 
enemy. Without the complete set of Ul, animation, 
art, rules, sound, effects and polish to present this 
system in a state that people could understand 
and feel good about, it was talked about in mostly 
abstract terms and only half-implemented. Most 
people— developers and Truth testers alike— were 
not excited about this feature for a longtime. 

Since Second Wind is part of the death and 
dying system, which ties in to both the economy 



aspects, until we got the consistency, flavor, 
and presentation just right. 

The secret to BORDERLANDS' success was 
that everyone felt that they could contribute 
to the game in a meaningful and original way, 
and every member of the team wanted to do 
exactly that. That's it. The way we feel about it 
is that we're proud of the game and everything 
we've accomplished, but we're really just 
getting started. ($> 

AARON THIBAULT is vice president of product 
development at Gearbox Software, helped produce 
BORDERLANDS, likes cake, and loves making games. 
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J0k Sound has always been an important part of the first 

^^^^^^^m person shooter experience. Not only does it enhance the 

09 ■ visual experience of the game, it also relays information 

■^L about the environment to the player. Since the player 

^Q^fcte^ cannot see everything at once, sound is often used to 

^^Q^^A inform the player about key events that are happening 
in the game and where those events are located. As 
HHfl H processing power becomes greater we are able to convey 

^■lJH this information to the player in a more realistic way by 
using sound propagation. 

Have you ever played a game where you're in a room 
and you hear a voice coming from another room? Did it sound as clear as day, 
thereby breaking the illusion the game was trying to create? That's where a 
sound propagation system comes in. 

WHAT IS SOUND PROPAGATION? 

» Sound propagation, put simply, is how a sound travels through a given 
space. In the context of an FPS, a sound propagation system allows the audio 
team to easily control the aural experience of the player moving through an 
interior space so that it sounds as natural as possible. 

For example, let's say you are in a room with a single opening (a door or 
window) and you are facing that opening. A sound is triggered to the right 



of you, outside of the room. Without a sound propagation system you would 
hear the sound from the right, as though there were no wall between you and 
the sound (see Figure 1). With a sound propagation system you would hear 
the sound coming from the opening in front of you (see Figure 2) with its 
volume attenuated, as well as occlusion applied to it, to convey that the sound 
originated from outside the room. 

WHY IS SOUND PROPAGATION IMPORTANT? 

» Aside from sounding natural, a sound propagation system provides some 
additional advantages for FPS titles. The first advantage is that it cleans up your 
mix without the need to turn off sounds that are happening outside the space 
the player inhabits. Let's take the example we used before— the room with one 
opening. Now imagine that there is a firefight happening outside of that room 
as well as a one-on-one shooting dual happening between the player and an 
opponent within the room. You will hear all of the chaos happening outside 
of the room, but aurally that chaos will be controlled because you will hear it 
coming from a single location (the doorway); it will be filtered so you know 
that it is happening outside of the room. Meanwhile, the one-on-one shoot-out 
within the room will be positioned as it would be normally and not filtered so 
that it stands out in the mix. 

The second advantage is that when a sound propagates through a space 
the player is informed that something is happening outside of the space they're 
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in, but they don't know exactly where that event is happening. This can be a very useful tool, especially in horror games, 
to convey a sense of mystery. 

STRAIGHT LINE DISTANCE VS. PATH DISTANCE 

» In order to build a sound propagation system, you first need to understand the difference between the straight line 
distance between a sound and the player, usually the game camera position in an FPS, and the "path distance" between the 
two. In an FPS, as the distance between a 3D sound and the player increases, the volume of that sound decreases (volume 
attenuation). When you play a sound and no sound propagation occurs, you use the straight line distance between the sound 
and the player to calculate the attenuated volume for the 3D sound. When sound propagation does occur, you need to trace a 
path from the location of the sound through every opening between the sound and the player. If there are multiple openings 
into the space the player is in you will need to trace a separate path to each of those openings. Once the path is traced you 
then use the cumulative distance of that path to calculate the attenuated volume. It's good to note that most audio middleware 
solutions handle volume attenuation internally so you will most likely not have to apply the new attenuation value directly to 
the sound. Rather, you will use the cumulative path distance to determine the repositioning offset for that sound. 

REPOSITIONING, OFFSETTING AND FILTERING 

» There are different ways to go about conveying that a sound is being propagated through a space. The first method 
is the repositioning of the sound to all the openings that connect the player's immediate surroundings to the space the 
sound occupies. If there is only one opening that connects the player's space to the sound's space, then the solution is 
easy— just move the sound to the location of the opening. 

But what if there are multiple openings? For each propagation path from the sound source to the player you must 




create a duplicate source positioned at the opening along the path between the player and the sound source. For Figure 2 Audio with sound propagation. 
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Figure 3 (left) One sound 
is propagated to multiple 
positions. Figure 4 (right) 
Offsetting sound to 
multiple positions. 



example, imagine the player is in a room with two openings and there are 16 sounds playing that can 
reach their ears along a path through either opening. Now you are playing 32 sounds instead of 16. 
When this happens you start running into a few problems. 

The first problem is voice starvation. Voice starvation occurs when you have too many sounds 
playing at one time. Once you have hit your hardware's audio channel limit the audio engine will 
either stop sounds that are currently playing or prevent sounds from playing, usually based on a 
priority value assigned to each sound. As you can imagine, once the bullets start flying this can 
become a big problem. 

The second problem is phasing. If you play two or more of the same sound at the same time there 
is a good chance that they will fall out of phase with one another, and you will get an undesirable 
flanging effect. When this happens, the audio sounds strange to the player, and you're worse off than 
you would be if you hadn't implemented a sound propagation system. 

Fortunately, there is an easy way to solve both of these problems. Certain audio middleware 
solutions, such as Wwise by AudioKinetic, allow you to take a single sound and play it from multiple 
positions in 3D space (see Figure 3). At runtime the multiple-positioning tech within Wwise will 
figure out what the volume for that sound should be in each speaker and process it accordingly. 

In addition to repositioning the sound to multiple locations, you also need to offset the 
repositioned sound from each opening based on the path distance between the sound and the 
opening (see Figure 4). If you do not do this the repositioned sound will play at full volume at each 
opening rather than playing at the appropriate attenuated volume. 

The second method to convey to the player that a sound is being propagated is by applying 
lowpass filtering to the sound. As a sound travels through a space it bounces off various surfaces 
and those surfaces absorb some of the high end frequencies from the sound. In an ideal situation 
you would perform ray tracing to find out what surfaces the sound is bouncing off of and how many 
times it bounces before getting to the player. Some sound propagation systems have done this, such 
as the one used in THIEF: THE DARK PROJECT (see Chris Carollo's GDC 2002 talk titled "Sound Propagation 
in 3D Environments" at www.gamasutra.com/gdcarchive/2002/chris_carollo.ppt). Unfortunately, 
that method requires too much processing power to be considered a viable method for a shooter 
that has hundreds of sounds within a short span of time. An alternate way to imitate this behavior 
in-game without using a lot of CPU power is by increasing the occlusion amount on a sound as the 
path distance from the sound to the player increases. This method is not totally realistic, but it gets 
the point across. 

INTERPOLATION AND LIN E-OF-SIGHT 

» Now that we've repositioned and filtered the sound we need to handle a few situations where we 
want to modify the position and filtering of the sound based on where the player is located in relation 
to the various openings in the room. 

Interpolation is a method of creating new data points based on a range of known data points. 
Interpolation can be used in a sound propagation system to smoothly move the position of a sound 
based on the player's position in relation to the openings in a room so that it always feels like the 
sound is coming through the openings. Let's go back to the example where we have the player in 
a room with one opening at the center of the wall in front of him. Since the opening is directly in 



front of the player, and you want the repositioned sound 
to feel like it's coming through that opening, there is no 
need to interpolate the position of the repositioned sound. 
Now let's take that player and place him up against the 
wall to the left of the opening. In this case if you want the 
sound to feel like it's coming from the opening you need 
to interpolate its position based on the player's position in 
relation to the opening (fig 5). If you do not interpolate the 
position the sound would feel like it's coming through the 
wall in front of the player instead of through the openingto 
the right of the player (fig 6). 

Another situation can come up if the player has line-of- 
sight to the sound through an opening. When this happens 
you will want to reduce the amount of filtering applied to 
the sound, as some noise will travel through that opening 
without bouncing off of any surfaces. You will also need to 
interpolate the amount of filtering applied to the sound so 
that the player doesn't hear a sudden jump in filtering when 
they go from having line-of-sight to not having line-of-sight. 

IMPLEMENTATION 

» Now that we've laid out the ground rules for a sound 
propagation system we can look at how to implement it. 
The first problem to solve is how to calculate the paths 
that a sound can traverse within a level. If you try to do 
this at runtime you will soon find that it takes way too 
much processing power. Therefore, you have to define 
the spaces that a sound can travel in the map editor, then 
store that path data into the map through a level build 
process. This data will then be loaded into memory when 
you play the level. 

Most 3D editors, such as the Unreal Editor, allow you 
to draw 3D volumes which the code can then reference to 
perform certain tasks. To define the areas you need, you 
can create specific sound propagation volumes within 
the level that mimic the geometry (see Figure ?). In this 
diagram, the sound propagation volumes are represented 
by the transparent pink boxes within the geometry. Notice 
that there are two volumes in this diagram, one for each 
room that a sound can path to and from. 

Now that we have defined the spaces that mimic the 
geometry, we have to define areas that connect those 
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spaces. We will call these sound propagation portals. Sound propagation portals will be created wherever you want a 
sound to pass through two connecting spaces, such as doors and windows (see Figure 8). 

Once all the volumes and portals are defined in the level the game engine can build the sound propagation path data 
and save it into the map. The generated paths will go from the center of each sound propagation volume to the center of 
each sound propagation portal connected to that volume (see Figure 9). The number of portals in a level directly relates to 
the amount of memory the sound propagation system will use at runtime. If you find out that the sound propagation data is 
taking up too much memory in a level, just remove some non-critical portals, such as windows or openings in a roof. 

At runtime, when a sound is triggered the sound propagation system will first find out what sound propagation volume 
the player is in, and what volume the sound is in. Then, through the sound propagation data that was saved into the map, it 
will find what paths connect those two volumes. Once the paths are found, the sound propagation system will reposition 
the sound to each portal connected to the volume with the player in it. The next step is to take the distance of each path 
and offset each of the repositioned sounds from the portal based on that distance. Finally, the position of the repositioned 
sounds should be interpolated based on the position of the player in relation to each portal (see Figure 10). 

WHEN TO USE SOUND PROPAGATION 

» Sound propagation works best when the player is in an interior space. Games where the player spends a good amount 
of time traversing narrow hallways and small rooms will benefit the most. This is mainly because the player's focus is 
narrowed by their physical surroundings, and they can concentrate more on where sounds are coming from. Once the 
player moves into an exterior space, sound propagation should be turned off, and you should just apply a lowpass filter 
to sounds that are blocked by large chunks of geometry to imply obstruction. 

There are also certain situations that occur when the player is traversing an interior space where you will not want 
to use sound propagation. The first is ambient and impressionistic sounds. A lot of times ambient sounds are crafted 
to convey an emotion for a specific space, and you do not want these sounds to bleed into another space. The second 
situation is in-game cinematics. Again, this is a situation where the sound designers know exactly how they want the 
event to sound and they should not have to worry about sound propagation adversely affecting the audio when it's 
triggered in-game. 

WHAT'S NEXT? 

» A sound propagation system needs a few fundamental features such as multiple repositioning and filtering of 
sounds in order to effectively convey to the player that a sound is traveling through a space. Once the basics are 
implemented you can start thinking about additional features, such as auto-generating sound propagation volumes 
as part of the sound propagation build process, modifying the wet/dry reverb ratio for propagated sounds, and how 
to handle obstructions in the path of a propagated sound. In the end, implementing a sound propagation system 
will not only make your game sound more realistic but it will also allow the game designers to convey information 
without presenting it directly to the player. 

The author would like to thank Ian Bond, Erik Irland, Chris Kline, and Shane Mathews from Irrational Games for help with 
the design and implementation of the sound propagation system described in this article. Without their hard work and 
dedication this system would never have been possible. 



SCOTT HARALDSEN is the Audio Lead at Irrational Games in Boston and has been designing sound effects and audio systems for the past 10 
years. He is currently working on Irrational Games' next big project. 
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Figure ? Volumes that represent 
geometry. 




Figure 8 The blue portal connects two 
sound propagation volumes. 




Figure 9 Path data generated from 
predefined volumes and portals. 




Figure 10 Sound being repositioned, 
offset, and interpolated. 
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FIGURE 1 A Cornell Box example. Each image is generated from the same data, rendered inside a game engine and only uses a single light 
source (no ambient). From left to right: dynamic lighting (in-game), lightmapping, and the result of combining the two effects together to 
achieve a strong specular highlight. 



COMING FROM A TRADITIONAL 3D 

background before moving into 
game development, radiosity-based 
lighting solutions have always been 
one of the most intriguing areas 
of 3D. To a traditional 3D artist, 
radiosity is truly the glue that binds 
everything together. Without it the 
most spectacular 3D art in the world 
can look flat and boring. With it, even 
the most mediocre 3D shapes can 
be turned into something breath 
taking and fascinating. So it should 
come as no surprise that radiosity- 
based solutions are a very attractive 
option for game development. 

Unfortunately, true real-time 
radiosity is very expensive and 
incredibly difficult to pull off even 
with today's best hardware, so 
game developers have had to settle 
for a static radiosity method called 
lightmapping, where advanced 
lighting data is baked into a bitmap 
image. While this method might 
seem obsolete to some, it is worth 
notingthat lightmapping continues 
to be a useful technique even against 
the modern dynamic lighting found 
in game engines due to its accurate, 
high quality results and very low 
overhead cost. In fact many of 
today's top games will actually use a 
combination of methods, with more 
emphasis on lightmapping and a 
small amount of dynamic lights, to 
get the best of both worlds. 

If there is one problem with 
lightmap usage in game development 
it is that there really hasn't been an 
affordable, user friendly, feature rich, 
high quality solution for developers. 
Typically what we find on the market 
are solutions that have two or 
possibly three of these qualities, but 
never all four. Thankfully this problem 
is about to be resolved with the 
arrival of pureLIGHT, a low cost yet 
feature rich lightmapping application 



for Unreal Engine 3, Torque 3D, and 
soon Unity. 

WHAT IS PURELIGHT AND WHAT 
MAKES IT SPECIAL? 

» At the heart of it all, pureLIGHT is a 
set of tools: preLIGHT and pureLIGHT, 
which are used as a one-two 
combination to generate high quality 
lightmap data for game engines. 

One of the most attractive things 
about pureLIGHT is the fact that 
the tool is incredibly affordable for 
any team to add to its production 
pipeline regardless of how large or 
small a studio it is. This affordability 
not only comes in the form of the 
low price of $500 for the software 
(which is not pertitle, like many 
other lightmapping solutions on the 
market), but also from the fact that 
you do not technically need to invest 
in additional rendering hardware 
to actually make the software 
usable! This is due to some truly 
novel logic and workflow practices 
that the software uses for lightmap 
generation. This allows you to operate 
off your desktop PC without ever 
sacrificing quality or requiring day- 
long renders where you cross your 
fingers and hope for the best. 

If this isn't impressive enough, 
pureLIGHT also allows a high 



degree of interactivity with your 
scene data through a variety of 
user friendly productivity features. 
It allows you to operate in a non- 
linear workflow and quickly correct 
any problems that you find through 
a well-thought out, novel approach 
to generating lightmap data. 

GETTING YOUR CONTENT READY 

» Working with pureLIGHT begins 
in your 3D digital content creation 
(DCC) application where you will 
prepare your data for export like you 
would for any radiosity generation. 
While it is possible to export your 
scene as a massive polysoup chunk 
for pureLIGHT to work with, the best 
results come from taking a bit of time 
to optimize and break the polygonal 
geometry of your scene into logical 
parts based on their need for lighting 
detail such as the floor, wall, and roof. 
Once that is done each geometric 
element, along with any lights you 
have set up and want to use for 
lightmap generation, need to be 
exported to either an ASE or Collada 
DAE file and tagged with a prefix to 
help pureLIGHT know how to work 
with the data you are supplying it. 

As an example, you would name 
the file forthe floor of a main hall 
"LM mainhallfloor" to define that 



you want this mesh lightmapped 
(LM). There are multiple prefixes 
that you can use to define other 
lightmap methods (which help 
define the UVW mapping) as well 
as prefixes for items like vertex 
lighting (VL), light sources (LS) and 
object lights (0L) to name but a few. 
Thankfully you do not need to worry 
about making a mistake here by 
assigning the wrong prefix, as you 
can correct this in preLIGHT. 

I should note that when dealing 
with the entire workflow process 
of pureLIGHT this was probably the 
slowest going, as there are no extra 
tools provided to help speed up your 
work in your 3D DCC application 
and this must all be done manually. 
That said, even with the extra time 
devoted to breaking up your scene 
and exporting, your work pays huge 
dividends in the end by enabling 
you to create fantastic results while 
maintaining fine control. 

CONVERTING AND OPTIMIZING 
THE 3D DATA WITH PRELIGHT 

» Once all your 3D data is exported, 
the next step is to load up a small 
conversion and optimization tool for 
pureLIGHT called preLIGHT which 
will help get all the exported data 
ready for lightmapping. Thankfully 
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In preLIGHT 
Input Rles | Log | Errors | Post Process 
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FIGURE 2 PreLIGHT's Post Process screen where you can tweak and optimize your elements to maximize UVW usage and lightmap size. 



in comparison to exportingthe 3D 
Data, converting your data through 
preLIGHT is an incredibly simple task 
that is mostly automated for you. 

One of the interesting things that 
I found when working with preLIGHT 
(and continuing into pureLIGHT) is 
that the software feels as though 
it has already been intensely 
production tested by its developer. 
You are not simply presented the 
expected basic options to mass 
convert all or selected files, there are 
also useful options to convert only 
files that have changed since your 
last conversion as well as options 
to tweak existing data to further 
optimize the lightmap generation. 

Regardless of what option you 
choose, in most cases preLIGHT will 



translate the data into an internal 
format for it to use to auto-generate 
and pack a second set of UVW 
coordinates for your 3D geometry 
specifically for lightmapping (unless 
you specify otherwise). I feel it is 
worth pointing out that preLIGHT 
actually does a pretty good job of 
creating this UVW data and packing 
it, unlike most auto generating UVW 
tools that you find on the market. 
Finally, if there is ever a problem 
with any of the data during the 
conversion process, concise error 
messages are displayed that will 
help you correct the problem in your 
3D DCC application. 

Once the conversion is done you 
can jump straight into pureLIGHT 
and start baking your lightmaps. 



However, preLIGHT also offers a 
set of tools in its Post Process tab 
that will help further optimize the 
lightmapping results. 

You can see the total video 
memory that will be used to lightmap 
the entire scene (which is always 
useful when you are on a budget) as 
well as information on each individual 
geometric element that you have 
converted. You're given information 
such as lightmap dimensions, texel 
size, a visual display of the current 
UVW clustering and packing, object 
types (which you can change), and 
most importantly, a set of options to 
adjust the UVW generation, packing, 
and lightmap dimensions. 

One of the most useful features 
in the Post Process tab is the UVW 
window and texel information. It 
not only shows a very clear picture 
of the UVW clusters that have been 
generated, but the window is also 
colored to display whetherthe UVWs 
are packed optimally orwasting 
memory. The closerthe UVW window 
color is to a bright green the better 
the UVW packing. 

Optimizing the UVW packing 
is done by adjusting the texel size 
value, which not only tweaks the 
packing results but can also adjust 
the lightmap dimensions, allowing 
you to create lightmaps with more 
or less detail depending on what 
they are needed for. 

It might sound like the work 
you need to do with preLIGHT is 
long and convoluted, but trust me, 



it really isn't. You can be in and out 
of preLIGHT with a very complex 
scene in less than 10 minutes and 
begin generating your lightmap data 
within pureLIGHT. 

THE EASY-BAKE 
PURELIGHT OVEN 

» The first thing I noticed when I 
loaded my scene into pureLIGHT is 
that the application feels more like 
a level editing application than a 
stuffy lighting tool. For example, all 
of the 3D and lighting data that you 
previously converted is displayed 
in real time (colored red to denote 
it has no lighting data) and you can 
toggle between selection and editing 
of objects and their properties in this 
scene. You have the ability to freely 
move about your scene even while 
bakingthe lightmaps using FPS-like 
controls via your mouse and WASD 
keys. Rounding out the interface, 
there is also a wide assortment of 
tools available to inspect and edit 
the properties of various objects 
and lights in the scene, including a 
function to return to preLIGHT and 
update an object. 

I found all these tools to be 
extremely useful when I needed to 
tweak something like the strength of 
a light, or modify the filter settings 
of an object in order to optimize 
the lightmap results. While having 
all these features may seem a bit 
daunting at first, you soon realize 
that they're just another set of useful 
tools to have available as an artist. 
They all helped me quickly refine the 
results with the least amount of pain. 

As for the lightmap generation 
itself, it's just as easy to work with 
as the rest of the software. Though 
it might sound a bit confusing, 
instead of always trying to perform 
the very best job possible the first 
time through, you have a powerful 
option within pureLIGHT to instead 
iteratively build the lighting data in 
multiple passes where you control 
the "sample rate" (essentially how 
many rays and bounces) of each 
pass that is performed. 

For example, a pass with a 
sample of 1 will finish quickly, but 
at a low quality. A pass at 16 will 
be more efficient, for extended 
bakes, and will ultimately produce 
the same results as 16 passes at 1 
sample. The main difference is that 
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a PRICE 
$500 



a SYSTEM 
REQUIREMENTS 

2 GB of RAM for 
pureLIGHT 32, 4 GB for 
pureLIGHT 64 
2.5 GHz CPU or 
higher (quad core 
recommended, more 
cores = faster baking) 
512 MBShaderModel3 



video card (ATI / NVIDIA). 
Video memory must be 
dedicated to the card 
(shared laptop memory 
is not supported) 
At least 2 GB free hard- 
drive space per large 
scene 

Windows XP or 

Vista (Vista x64 

recommended) 

64-bit operating system 

required for 64-bit 

pureLIGHT 

March 2009 DirectX 

Runtime 

Microsoft .Net 3.5 SP1 
Visual C++ 9 SP1 or 



2008 SP1 Runtime 
(provided with installer) 

a PROS 

1 No render farm required. 

2 Real time interactivity 
even while baking. 

3 You do not need to re- 
render an entire scene 
to fix problems. 

a CONS 

1 Windows PC based. 

2 Could use more 3D 
DCC tools for a faster 
export of assets. 

3 Only works with 3D 
DCC tools that can 
export ASEorDAE. 
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The interactive pureLIGHT editor processing a demo scene converted for 
testing from an existing Torque3D level. Here the scene is processing on a dual core 
box (16 samples) while staying completely interactive in real-time. 




PureLIGHT was used to help stylize the final look and feel of Andrew 
Czarnietzki and Nathan Rossol's Unreal 3 level Hanging Gardens which was a finalist in 
this year's Make Something Unreal competition. 




on the lower sampling numbers, you 
will very quickly get an idea of what 
the final result will look like, which is 
ideal for prototyping. 

Because it operates via passes 
and sample rates, you are able to stop 
or pause the lightmap generation, 
even in the middle of a pass, while 
still retaining all the data that has 
been generated. This is extremely 
useful when you are navigating 
the scene in real time and spot an 
issue with an object that you need 
to correct in your 3D DCC application 
or fix inside of preLIGHT. Once you 
have the issue corrected, you can 
return back into pureLIGHT and 
continue rendering right where you 
left off! The changed data is quickly 
updated and brought up to sync with 
the other data in your scene. As you 
can guess, this is a process that is 
recommended by the developers 
of pureLIGHT (and something I can 
definitely attest to as extremely 
useful) for rapid development of your 
scene regardless of whether you are 
on a single computer or distributing 
the rendering via a network. 

This isn't all that pureLIGHT 
offers as far as real-time user 
interactivity either. PureLIGHT offers 
the ability to hide objects from being 
calculated in the lightmap pass but 
without negatively affecting the 
lightmap generation of other objects 
in the scene. When combined with 
the fact that pureLIGHT prioritizes 
lightmap rendering on objects that 
you are currently viewing with your 
camera, you have the ability to 
selectively prioritize rendering to 
locations within your scene. 

Another feature that was just 
recently implemented in pureLIGHT 
is the ability to have the software 
act like a traditional 3D rendererand 
generate an image of the scene from 
the current camera position. While 
the render is not instantaneous it is 
another useful tool for optimizing a 
scene's results since it gives a very 
accurate representation of what the 
final lightmap result will be without 
the need to actually spend time 
generating the lightmaps. 

Some of the other useful features 
I found within pureLIGHT include the 
ability to increase or decrease light 
strength either on selected lights or 
globally across all lights (which is 
handy for those fine adjustments 



that you need to make from time to 
time), the ability to create new point 
or spot lights, distributed network 
rendering, bitmap blurring, and 
control over the filter and color bleed 
settings on a per-object basis. 

Now all these fantastic features 
are great at making the end user 
experience a satisfying one but the 
real question is, "How good are the 
results that pureLIGHT produces?" 
You will be pleased to know that 
nearly everything you would want 
and expect from a radiosity solution 
is here, such as direct and indirect 
(bounced) lighting, light/ray casting 
from spot, point, and object, texture 
lighting support, soft/diffused 
shadows, vertex lightmapping, color 
bleeding (the transmittance of color 
from one surface onto another), per- 
object and per-pixel transparency 
transmittance, and most caustics. 

In fact the only significant 
radiosity feature that pureLIGHT 
appears to be lacking at this time is 
support for a few of the more under- 
utilized caustic effects in games 
such as water, mirrors, and glass 
reflection/refraction. Animated lights 
are obviously not directly supported, 
since that would defeat the purpose 
of static lightmapping, but there are 
options within pureLIGHT to pull it 
off by cycling through a series of 
generated lightmap images. 

PureLIGHT also has the ability 
to export your scene into a playable 
mission or level file for the game 
engines that it supports. It does 
this fairly easily and in my testing 
I never had a problem with the data 
comingthrough incorrectly or not 
being copied to the proper directory. 
Also should you ever get lost or 
need more information on how to 
utilize the software, it ships with a 
fantastic set of in-depth written and 
video documentation which goes 
into far more detail than I have here. 

LIGHTS UP 

» There is a lot that I could continue 
to write about pureLIGHT from the 
features to the fantastic results that 
it generates (which are easily on 
par with any other offering available 
for game developers). This tool lives 
up to all its expectations and more 
by being an affordable solution that 
provides high quality results and a 
rich user interactivity that empowers 



artists to work naturally which is 
definitely a refreshing change. 

PureLIGHT is a tool that you 
should look at plugging into your 
art pipeline. Its affordability 
combined with a plethora of easy 
to learn, user-friendly features 
and its impressive and accurate, 
lightmapping results make it a 
very easy solution to consider 
adding to projects. (ID 
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CONTROLLING PROCEDURALLY GENERATED CONTENT FOR FUN AND PROFIT 



THE WORDS "PROCEDURALLY GENERATED 

content" seem to be coming up a lot lately. I 
swore never to start an article with a definition, 
but a little clarity goes a long way in this case. 
Procedurally generated content is anything that 
exists in a game that wasn't strictly scripted that 
way by a designer. It might be a dynamically 
generated dungeon or a randomly rolled 
adventurer. Anything that exists in the game 
at any moment that is authored more by the 
computer than by the designer is fair game. 

It sounds odd, but physics middleware 
is probably the most popular expression 
of procedural generation in games today. 
Physics engines reduce the need for special 
case animations and scripting, which reduces 
strain on content pipelines. More importantly, 
though, physics engines allow for unpredictable, 
emergent behavior that is impossible with 
scripted content. Without this stuff, there is no 
halo, no Grand Theft Auto, no world of Goo, no 
Little Big Planet. 



This mental activity of pitting our own internal 
predictions against the actual simulation is an 
inherently compelling and powerful process. This 
is how we engage with everything around us on a 
day-to-day basis. This is science. 

We are not going to explore physics engines 
today. We are going to explore everything else: 
controlled random numbers, graph systems, 
obfuscation, anything that makes game systems 
more interesting. We are going to look at what 
powers SlMClTY, DIABLO II, and SPELUNKY. We 
are going to make predictable systems more 
surprising, and we're going to sculpt random 
generation into a useful tool for any game. 

SEEDED RANDOM NUMBERS 

» Let's get this one out of the way; it's pedantic, 
but necessary and thankfully easy. Forthe sake 
of debugging, playtesting, and recording replays, 
your system absolutely must support predictable 
random number generation. This is known as a 
"seeded" random number. You provide a "seed" 



We like physics because we understand why things 
happen. Physics has accountability. We might not 
know exactly where we will land after we go off this 
sweet jump, but we know when we hit it, we will go 
rocketing off into the stratosphere and it will be rad. 



But it's not just emergence that fuels 
our love of physics. Flipping a coin creates 
unpredictable results too. We like physics 
because we understand why things happen. 
Physics has accountability. We might not know 
exactly where we will land after we go off this 
sweet jump, but we know when we hit it, we 
will go rocketing off into the stratosphere and it 
will be rad. Even though we don't have a perfect 
predictive model forthe game's physics in our 
heads, we kind of have a rough idea about what 
is going on. 



that will generate the same random number each 
time the equation is called. The Mersenne Twister 
is one popular algorithm that is fairly high fidelity. 
If you are only developing for one platform, 
chances are it provides an API call like s rand () 
or something similar. My flash games use a 
simple but low fidelity cross-platform algorithm: 

random = ((69621 * int(seed * 
0x7FFFFFFF) ) '/, 0x7FFFFFFF) / 
0x7FFFFFFF ; 



In this equation, the variable "seed" is a floating 
point number from 0 to 1. This equation changes 
it to a predictable but pseudo-random value in 
the same range, 0 to 1. For example, if I pass it 
the value 0.1, it might return 0.675. But it will 
return 0.675 every time I give it 0.1, which makes 
it very useful. If you want to generate a series of 
numbers from the same seed, you can "mutate" 
the seed by the new random number: 

if(seed += random > 1) seed -= 
int (seed) ; 

Now you can calculate a new random number 
from your new seed, which was mutated in a 
predictable way. This works pretty great even for 
non-linear games. For example, if you have a hub 
world and a bunch of randomly generated areas 
to explore, you can store different seeds for each 
area so they are generated predictably, no matter 
the order in which they are visited. 

CONTROLLED RANDOM NUMBERS 

» Now that we have a good basic system for 
generating random numbers, we can start the 
proper science! Imagine you are playing a card 
game. In this game you draw a card from the 
deck, note its suit and value, return it to the 
deck, shuffle the entire deck, and draw again. 
You can get any card on any draw; it's extremely 
unpredictable and the odds never change. 

Now think about how most card games 
actually work. You shuffle the deck once, and 
keep drawing from the deck until you've pulled all 
the cards. If any of the elements you're shuffling 
stand out in any way, their mere presence or 
absence is instantly significant. If you've ever 
played or watched a game of Blackjack, you know 
how the game changes when you make it halfway 
through the deck without pulling any face cards. 

By changing the pool of elements as you 
progress, you are changing the system itself. The 
first example seems more random, but in practice 
it is less dynamic, less interesting, and more 
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frustrating. It's also very shallow; with practice, 
players can learn to count cards in the second 
system, inherently providing a whole new level 
of play. 

This is really easy to code, too. Instead of just 
asking for a new random number each time, you 
just load up an array with sequential possibilities, 
and "shuffle" it ahead of time. Then instead of 
asking for a new random number you just grab 
the next number in the array. Result: instantly 
more interesting game. 

MATCHING SUBSETS 

» Another easy way to constrain a random 
generation system is to choose a small subset 
of elements from a larger pool of items. To use 
the deck of cards again, if you only play with 
spades then you are guaranteed to get a nice set 
of values each time, instead of getting repeated 
values in different suits. 

This is used to great effect in nearly all 
collectible card games, from Magic: The Gathering 
to Dominion. By limiting the player's selection 
at the start of the game, you reduce the number 
of elements at play to a manageable quantity. 
In recent video game history, SPELUNKY groups 
specific enemies, tilesets and other features 
into groups like Jungle or Ice World to establish 
progress and manage anticipation. 

The obvious benefits of this approach are 
diversity and control. For example, if your game 
features flaming enemies and a water gun, you 
might want these things to appear with some 
proximity to each other. Like controlled random 
numbers, it seems much less random but prevents 
corner cases like spawning a bunch of the same 
enemy, just in different colors, and ensures that 
compatible game elements show up together. 

GRAPH SYSTEMS 

» This section could be an entire article on 
its own, but we have to at least touch on some 
of these basic algorithms here. Graph systems 
describe different interesting ways of creating 
things like terrain or environments for your game, 
and most of them are pretty simple. 

Node-based systems. These are the easiest to 
implement. In a node-based algorithm you just 
scatter points around your potential playspace. 
Even if your game requires fully realized geometry 
or geography, it's not rare to find, somewhere in its 
generation code, a system that involves scattering 
some dots around (see Figure 1). 

WEIRD WORLDS: RETURN TO INFINITE SPACE uses 
a node-based system for its star map. Of course, 
like all these systems, node-based layouts work 
best with some constraints. An easy brute force 
method of controlling node proximity is to do a 
basic distance calculation against other extant 



RE 1 Randomly scattered dots. 



FIGURE 2 Dots scattered within a grid. 




Randomly-arranged tiles create interesting 



playfields. 



nodes before you create a new node. A less CPU- 
intensive method involves dividing your play 
area into a grid, and only generating one node per 
padded grid block (see Figure 2). 

This approach requires some finesse, 
and sometimes generates arrangements that 
are too on-grid. However, it is easy to control 
density and arrangement simply by changing 
the grid size or skipping some blocks. You can 
also layer your node system, like placing stars 
around black holes, and planets around stars. 
This is the simplest and thus most flexible 
generative template. 

Tile-based systems. These are also pretty easy 
to implement, and are used to great effect in 
games like SETTLERS OF CATAN and SPELUNKY. A 
"tile" in this case is a medium-sized, meaningful 
piece of geography. These tiles are randomly 
arranged (though frequently with some 
constraints) to create the terrain or playspace of 
the game (see Figure 3). 

If you occasionally want your game to 
create an extra-large desert with an oasis in the 



FIGURE 4 Intelligent tiling can lead to auto-generated 
maps. 

middle, or a deep crevasse in your platforming 
game, you can deliberately link your game tiles 
into larger "meta-tiles" for additional variety and 
interest. Tiles can also be pre-loaded (randomly 
or not) with enemies, traps, resources, and 
path-finding information. 

Corridor algorithms. Corridor algorithms are 
another set of graph systems that create 
believable, interesting environments. They do 
not take things like gravity or jump distances 
into account, so are better suited to top-down or 
flying/floating games. This basic approach was 
popularized by text-based dungeon crawlers like 
ROGUE or NETHACK. Like tile-based routines, these 
systems start by dividing the play area into a grid 
(see Figure 4). 

First, we pick a grid cell at random. Then we 
pick a disconnected neighbor block, connect to it, 
and repeat. When we run out of open blocks, we 
go through each block in the grid and draw rooms 
and hallways according to the connections you 
mapped. We put the start of the level in our first 
block, and the end in the last block. I will leave it up 
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to the reader to invent ways to augment this basic 
algorithm to create more interesting environments! 

These are just some of the basic graph 
systems you can start with. Other games might 
use Perlin noise to generate heightmaps. I wrote 
a demo that simulates meteors and volcanoes 
to create a quantized height map fortiled JRPG 
overworlds. Urban environments might use 
entirely different, more geometrical methods 
to produce believable game worlds. I used an 
impromptu mix of nodes, tiles and corridors 
together to generate the underwater labyrinths 
in FATHOM. These things are not so much finite 
categories as ways of thinking about the different 
expressions of graph systems. 

DELAYS AND OBFUSCATION 

» Players, being human, have to create patterns, 
and have to find order in chaos. If they fail, they 
become frustrated; the system is too arbitrary. 
However, if everything is in perfect order and 
there are no surprises, the player will be bored to 
tears. This is why we have been exploring ways 
to add reason to the randomness, and designing 
systems that organize unpredictable quantum 
bits. These systems generate surprising results, 
but the player can intuitively understand them on 
some level, and can strategize or at least relate to 
the results. They're not just random. 

We can approach this problem from the other 
side, too. Instead of trying to sort random numbers, 
we can hide or mess up ordered numbers. My 
favorite real-world example of this is the stock 
market and quarterly financial reporting. Even 
though corporations and the stock market operate 
on a moment-to-moment basis, many investors 
only make real decisions about their shares three 
to six months after a big business decision is made, 
when the quarterly finances are reported. 

So, in the meantime, the users and players in 
this system are forced to invent their own internal 
models and projections so that they can make 
educated guesses without having to wait three 
months. These models are sometimes grossly 
inaccurate. This is also how science and divorces 
work! Either way, it leads to all sorts of interesting 
side effects and feedback loops, exactly the sorts 
of things we are interested in. 

Will Wright's masterpiece SlMClTY is probably 
the best example of using delays and obfuscation 
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hiding and delaying the effects of your decisions. 
Sometimes the results of a simulation might 
be piped into other simulations, which are then 
pushed off into even more simulations, so the 



effects that you see are amplified or distorted in 
interesting ways. However it is accomplished, the 
results can be really engaging. 

CIRCLES AND ARCS 

» Like physics middleware or hiding numbers, 
circles may sound like a strange way of thinking 
about procedurally generated content, but 
bear with me. By definition, a circle's surface is 
constantly varied; no two points on a circle have 
the same tangent line. All circles have a radius, so 
when two circles collide, what we know to be very 
simple geometry suddenly becomes very difficult 
to precisely visualize, as we project the angles 
and radii and try to guess what will happen. 

Circular collisions fascinate me because 
they give us exactly what we are looking for 
in an interesting system of game logic. The 
rules are easy to understand, and forming a 
rough mental model of what might happen is 
effortless, but it's very hard to predict exactly 
what the results will be. And even if the results 
surprise us, we can tell why it happened, and 
update our mental model accordingly. 

Pocket billiards is obviously a perfect example 
of circular physics providing an interesting game 
system. More recently, a little game called PEGGLE 
showed that circular collisions are still fascinating 
to normal people too. However they are arranged, 
simple simulations suddenly become much more 
interesting when they're curved. 

PITFALLS 

» All these systems, despite their obvious 
promise, are fraught with potential disasters, many 
due to players' aforementioned need for pseudo- 
predictable surprises. If your algorithm is too 
predictable and well-ordered, players will become 
bored or hack the system. If it's too obtuse and 
unpredictable, players can't explain inconsistencies 
and will be frustrated or overwhelmed. 

If the system is unpredictable but too 
transparent, players might feel like they have 
been given a randomized checklist, which is just 
as boring as a sorted checklist. If the game is 
fundamentally about precision or competition, 
the introduction of unexpected elements can 
be immensely frustrating. Even in games where 
chaos is the norm, small changes to algorithms or 
the way simulations are communicated can mean 
huge differences in payability. 

CONTROLLED CHAOS 

» This article represents just a fraction of the 
ways that procedurally generated content can be 
interpreted and used to create more interesting 
games. Think about how games mix and match 
just these few simple systems to create their 
unique presentation. Think about how these 
things could apply to art and music. Think about 
using these systems in reactive ways, so that the 
game's look, feel, and sound alter according to 



the player's behavior. This isn't just an interesting 
facet of game design; it is game design. And we 
barely know how to do it. 

Earlier this year I spent a week paddling down 
the Grand Canyon. We floated past hundred-year old 
USGS sites, million-year old remains of underwater 
rivers, and billion-year old basement granite 
rising vertically from the water's edge. We were 
passengers on a river pumping tens of thousands of 
cubic feet of water per second, changing itself and 
the rocks around us while we watched. 

There are fundamental, universal truths at play 
in these simple, dynamic systems: stringtheory, 
global economics, the big bang. Learning from 
games using the same schema or models that we 
develop trying to understand our own complicated 
world is much more interesting than simply 
memorizing the developer's arbitrary intent by trial 
and error. These systems inherently encourage 
gratifying, intuitive problem solving over brute- 
force, algorithmic solutions. They allow for real 
replay value, they reduce special-case content, 
they encourage exploration and experimentation, 
and they level the playing field between gamers 
and non-gamers. What more can you ask for? CD 



ADAM 'ATOMIC SALTSMAN is an independent game designer, 
co-founder of Semi Secret Software, and creator of Flixel. He 
makes games in Austin, TX with his wife Bekah and two idiot 
pug dogs. 
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DESIGN OF THE TIMES // SOREN JOHNSON 



THEME IS NOT MEANING 

PARTI 



WHO DECIDES WHAT A GAME IS ABOUT? 

At first glance, the popular board game Ticket 
to Ride seems to be another link in the great 
chain of rail baron games, such as Age of 
Steom, Euroroils, and the 1830 series. During the 
game, the player draws unique route challenges 
to connect certain pairs of cities— New York to 
San Francisco, Miami to Chicago, and so on. 

To complete them, she must claim a series 
of tracks that connect adjacent cities while also 
tryingto block her opponents from finishing their 
own challenges. There are sub goals too, such 
as having the longest contiguous rail line and 
completing one's network first, which ends the 
game for everyone. 

Thus, most players would describe Ticket 
to Ride as a game about building the best rail 
service by grabbing choice routes and cutting 
off the competition. However, the introduction 
in the rules tells a different story: "On a blustery 




autumn evening five old friends met in the back 
room of one of the city's oldest and most private 
clubs. Each had traveled a long distance— from 
all corners of the world— to meet on this very 
specific day ... October 2, 1900—28 years to 
the day that the London eccentric, Phileas Fogg, 
accepted and then won a £20,000 bet that he 
could travel Around the World in 80 Days. 

"Each succeeding year, they met to celebrate 
the anniversary and pay tribute to Fogg. And 
each year a new expedition (always more 
difficult) was proposed. Now at the dawn of the 
century it was time for a new impossible journey. 
The stakes: $1 Million in a winner-takes-all 
competition. The objective: to see which of them 
could travel by rail to the most cities in North 
America— in just ? days." 

The official story comes as a surprise to many 
players, even veterans of the game, because the 



theme simply does not match the gameplay. For 
example, how can a player "claim" a route just by 
riding on it? Do the trains shut down, preventing 
anyone else from using that line? On the other 
hand, claiming routes matches perfectly the 
fiction of ruthless rail barons trying to control the 
best connections. 

Furthermore, routes can be claimed in any 
order— there is no sense that the player actually 
exists in the world as a traveler with real, physical 
limitation. Instead, claiming routes feels a lot more 
like buying them ratherthan traveling on them. 

MECHANICS GIVE MEANING 

» This disconnect leads to some interesting 
questions. Does a game's designer have the right 
to say what a game is about if it doesn't match 
what's going on inside the players' heads? And if 
the designer doesn't have this right, then does a 
game's official "story" ever matter at all, since it 
can be invalidated so easily? Isn't a game about 
what one actually does during play and how that 
feels to the player? 

Ultimately, designers need to recognize 
that a game's theme does not determine its 
meaning. Instead, meaning emerges from a 
game's mechanics— the set of decisions and 
consequences unique to each one. What does 
a game ask of the player? What does it punish, 
and what does it reward? What strategies and 
styles does the game encourage? Answering 
these questions will reveal what a game is 
actually about. 

Furthermore, while people buy games for 
the promise of the theme ("I want to be a space 
marine!"), the fun comes from the mechanics 
themselves (actually shooting the aliens). When 
there is a severe dissonance between the two, 
players can feel cheated, as if the designers 
executed a bait-and-switch. 

The reception of SPORE, a game sold with an 
evolutionary theme, provides a recent example. 
In the October 2008 issue of Science magazine, 
John Bohannon wrote the following about 
how the game delivered on the theme's 
promise: "I've been playing SPORE with a team 
of scientists, grading the game on each of its 
scientific themes. When it comes to biology, and 
particularly evolution, SPORE failed miserably. 
According to the scientists, the problem isn't just 
that SPORE dumbs down the science or gets a 
few things wrong— it's meant to be a game, after 



all— but rather, it gets most of [its] biology badly, 
needlessly, and often bizarrely wrong." 

The source of this dissonance is that, even 
though it was sold as such, SPORE is not really 
a game about evolution. SPORE is actually a 
game about creativity— the reason to play the 
game was to behold the wonder of other players' 
imaginations as they used (and misused) the 
editors to create objects not imagined by the 
game's designers— from musical instruments to 
fantastical creatures to dramatic scenes. 

However, even though SPORE is not about 
evolution, the scientists should keep looking 
because one of the most popular games in the 
Western world actually is about evolution— 
WORLD OF WARCRAFT. The game may have a 
swords-and-sorcery theme, but the mechanics 
encourage the players to conduct their own 
form of natural selection when deciding how to 
develop their characters. 

Overyears of experience, veterans ofWoW have 
established a number of upgrade paths (or "builds") 
for each class, depending on what role the player 
wants the character to fill. For example, the Paladin 
class has three main builds: Holy (for healing), 
Protection (fortanking), and Retribution (for 
damage-per-second). Further, underneath these 
main categories, sub-builds exist for player-vs- 
player, player-vs-enemy, and mob grinding. These 
paths have evolved organically over the years as 
players tried out different combinations, depending 
on what the game rewarded or punished. 

SEEING PAST THE THEME 

» One can look at any number of games 
through the lens of how the mechanics affect 
the user experience to find out what the 
game actually means. SUPER MARIO BROS., for 
example, is a game about timing, certainly 
not about plumbing. BATTLEFIELD games are 
about teamwork, not World War II or modern 
combat. PEGGLE is a game about chaos theory, not 
unicorns or rainbows. 

Indeed, games with the same theme can 
actually be about different things. For example, 
human conflict with aliens has certainly been 
a popular theme across video game history. 
Nonetheless, each alien-themed game can mean 
something very different depending on the rule 
set. GALAGA is actually about pattern matching. X- 
C0M is about decision-making with limited 
information. GEARS OF WAR is about using cover 
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Spore is a game about social experimentation, not evolution or biology 



as a defensive weapon. STARCRAFT is about the 
challenges of asymmetrical combat. 

Conversely, games with different themes but 
the same mechanics are actually about the same 
thing. CIVILIZATION and ALPHA CENTAURI are set on 
completely different planets, but the mechanics 
are largely the same. ALPHA CENTAURI's mind worms, 
probe teams, and Secret Projects are essentially 
identical to CIVILIZATION'S barbarians, spies, and 
World Wonders. Players can easily see past the 
game's chrome to see that they are still making the 
same decisions with the same trade-offs. 

Genre choice can also affect the meaning 
of a game. Players expect a theme to deliver on 
certain nouns and verbs. ("I am a Mage— I can 
cast powerful Magic!") Unfortunately, genre 
conventions often put a barrier between a player 
and the game he imagined while holding a copy in 
the store. Once again, players buy games forthe 
theme as presented on the box— if the mechanics 
and traditions of the genre are wildly unfamiliar 
to the player, at odds with the game in his head, 
he may feel cheated. 

For example, two recent console games— 
Halo Wars and Brutal Legend— surprised players 
by being strategy games. With the former, many 
players expected a HALO game to be about reflex- 



based combat; with the latter, the heavy-metal 
aesthetic was not viewed as inherently strategic. 
Because strategy games are often played at 
a considered distance, players expecting the 
visceral thrill promised by the games' themes 
were disappointed. The designers may have built 
fun and interesting rule sets, but the themes sold 
the games to the wrong fans. 

UNITING THEME AND MECHANICS 

» One interesting comparison is the board 
games Risk and Diplomacy, which have identical 
themes of world conquest. Indeed, at first 
glance, the two games also seem quite similar 
mechanically. The game board is split up into 
territories, which the players control with generic 
army or (in the case of Diplomacy] navy tokens. 
These territories switch hands as battles are 
fought, and— in turn— the victors are able to field 
larger militaries from their new lands. 

However, a small difference in the rules 
makes the two games about something very 
different. In Risk, turns occur sequentially while, 
in Diplomacy, they execute simultaneously. 
This difference makes Risk a game about 
risk while Diplomacy becomes a game about 
diplomacy. In Risk, players must decide how 



much they can achieve during their own 
turn and then hope the dice are not unkind. 
With Diplomacy, however, there are no dice; 
players can only succeed with the help of others, 
which can only be promised but not actually 
delivered during the negotiation round. Only when 
the secretly-written orders are revealed between 
turns is it clear who is a true friend and who is a 
backstabbing traitor. 

Diplomacy, in particular, is a perfect 
marriage between theme and mechanics. 
Indeed, President John F Kennedy considered 
it his favorite game. The game is about exactly 
what it claims to be about— the twists and 
turns of diplomatic negotiations. On the other 
hand, when a game's theme and mechanics are 
sharply divorced, players can react negatively 
to the dissonance. In part II of this article, we 
shall discuss examples of games which made a 
successful union of the two and ones which did 
not— and the rewards and costs of doing so. (£> 

SOREN JOHNSON is a designer/programmer at £A, working 
on browser-based strategg games at www.strateggstation. 
com. He was the lead designer of CIVILIZATION IV and the 
co-designer of CIVILIZATION III. Read more of his thoughts on 
game design at www.designer-notes.com. 
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PIXEL PUSHER // STEVE THEODORE 



PUSHBUTTON ART? 

PROCEDURAL IS THE NEXT BUZZWORD 




ART HAS ALWAYS BEEN ABOUT 

getting your hands dirty. Go back 
far enough and that could be very 
dirty indeed: If you went to the 
Renaissance version of Full Sail or 
the Art Institute, you would spend 
most of your days up to your 
elbows in boiling sheep carcasses 
and egg yolks, learning how to 
make the tools of the trade. In the 
contemporary art world things are 
a bit more sanitary (unless you're 
Damien "Shark-in-Formaldehyde" 
Hirst), but artists still revel in 
the physicality of their materials: 
painters love paint, sculptors caress 
clay, pencillers long for rich vellum 
and needle-sharp Koh-I-Noors. 

Game artists, of course, are 
underserved in the physicality 
department (unless you count the 
funk of an overcrowded cube farm 
at one in the morning). Game art 
tilts toward the cerebral and away 
from the visceral. We spend more 
time juggling trade-offs between 
production costs and runtime 
resources than communing with 
the Muses. This doesn't make us 
full-fledged rocket scientists (just 
ask programmers!) but it does 
locate us in a strange never-land 
between the immediate world of 
the traditional arts and the abstract 
realms of computation. 

Changes in technology and 
large-scale market forces look 
ready to shift the boundaries 
of our little kingdom. Fifth-Gen 
consoles ("Next Gen" is so 2000s!) 
like the 360 and PS3 have taught 
audiences to expect movie-quality 
graphics. Open world games, from 
WOW to GTA, have taught players to 
just hop onto a hippogrif (or into a 
jacked-down Honda with phat rims) 
and head for the horizon. The fatal 
combination of open environments 
and sky-high graphics standards 
has meant exploding budgets, 
giant teams, and the rise of a global 
outsourcing industry. Against this 



backdrop, any technology that 
promises to shrink team sizes 
and budgets looks extremely 
attractive. This means you can bet 
that procedural content is going to 
continue to be a hot buzzword in 
the coming decade. 

BYTHE NUMBERS 

» Procedural is just the fancy way 
of saying "computer generated." We 
use procedural tools and techniques 
all the time: particle systems, 
ragdolls, and even noise textures 
all fit the dictionary definition of 
"procedural." However the word 
is more commonly reserved for 
advanced tools that generate 
content automatically (see this 
month's Inner Product, Pg. 40, 
for more). In other words, it's the 
perennial fantasy of every harassed 
producer: the artist-on-a-disk. 

The procedural tools already 
in common use are diverse, but 
they all have one thing in common: 
controlled chaos. Sprinkling ground 
cover across a landscape, dirtying 
up a texture, or ejecting gibs from 



an explosion are examples of 
procedural tools we use every day. 
They all demand a level of visual 
noise which is tedious to create 
by hand. If you want a bunch of 
mountains, but you don't care much 
about any of them individually, it's 
a quicker to let a fractal algorithm 
push some verts around for you 
than to drive some poor artist batty 
doing the same thing by pulling 
vertices. You could certainly hand- 
animate a bunch of sprite cards to 
create a smoke plume, but its faster 
and easier to hand that off to a 
particle system. 

Noisy, messy subject matter 
reflects the fact that most of these 
simple procedural techniques 
are little more than pimped-out 
random number generators. 
They're the digital equivalent of 
scribbles: random stuff that's 
handy for suggesting the feeling of 
complexity. In a word: filler. Games 
with completely "procedural" 
landscapes and textures crop up 
now and then, but few have much 
staying power. Good art is all about 



the interplay between structure 
and wildness, not just randomness 
straight from the can. 

WOODMAN, RE-PARAMETERIZE 
THAT TREE! 

» In the last few years, though, 
proceduralism has started to 
outgrow fractals and Perlin noise 
and moved into more challenging 
territory. Tree simulations showcase 
the trend— lots of studios use 
products like SpeedTree orXFrog 
to crank out forests by the digital 
acre. This is an exacting task which 
demands both randomness (no two 
trees are alike) and obedience to 
a very complex set of rules (pine 
trees are all similar to each other, 
but all different from oaks). 

As you'd expect, tree sim 
applications are light years beyond 
simple noise functions. They expect 
the user to control the entire tree- 
generation algorithm itself. Rather 
than simply twiddling a handful of 
parameters, the user has to assemble 
a set of procedural rules by which 
the tree will be generated. Does 
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FIGURE 2 This street scene was generated entirely with Tyson Ibele's BuildingGenerator 
MaxScript. It shows both the power and the limitations of procedural building generation. 
The script can be found at http://tysonibele.com. 



the tree start bifurcating right from 
the ground, or only above a certain 
height? Do new branches droop 
toward the ground, climb forthe sky, 
or just start out randomly? Do leaves 
get smallertoward the crown of the 
tree, or perhaps towards the end of 
the branches instead? Only once 
you've established the basic rules 
for these sorts of choices do you 
start twiddling sliders for obviously 
"parametric" things like the height of 
the tree or the number of branches. 

The final result reflects 
randomness and user parameters, 
but also the overall structure 
embodied in the rule set. Ideally this 
captures both the individuality and 
the family resemblances among 
many different types of trees. As 
you can see in Figure 1, the results 



can be extremely impressive. Only 
a tremendous amount of hand 
work can rival the visual complexity 
and consistency of a well-tuned 
procedural tree. 

Unfortunately, as the figure also 
suggests, managing the procedural 
setup can demand an equally 
tremendous amount of work. If you're 
only interested in quick content 
(the forest, as it were, rather than 
the trees) tree sims do a great job 
right out of the box. If you need more 
precise artistic control— say a hero 
asset that matches the rest of your 
game but has important gameplay 
functions too— things get dicey. 
With so many cascading rules to 
grasp and so many interdependent 
parameters to tweak, many users 
never get beyond the presets that 



ship with their packages. There's a 
reason veteran tree creators can 
usually guess which tree software a 
given game uses. 

Getting really precise artistic 
control of a complex procedural 
system requires left-brain-y thinking 
about abstract rule systems, which 
means it requires an uncommon 
kind of artist. Somewhat like shaders, 
procedural systems tend to attract 
specialists with a lot of patience and 
insatiable curiosity. Also like shaders, 
procedural tools intimidate a lot of 
other artists. Interestingly (and again 
as with shaders), the tools vendors 
are groping for ways to let technical 
artists "teach" the procedural 
systems by example. This is an 
attractive alternative to traditional 
logic trees or HyperGraph-style 
node networks. The latest version of 
SpeedTree, for example, allows you 
to interact directly with a procedural 
tree— by drawing in a new limb, say, 
or explicitly adding broken branches 
and twists where you need them. 
This kind of authoring still demands 
more from your inner nerd than just 
grabbing verts and pulling— but it's a 
damn sight closer to visceral, roll-up- 
your-sleeves art than fiddling with a 
window full of sliders. Expect to see 
more simulation training in the next 
couple of years. 

BUILT IN A DAY 

» Tree sims are not the only area 
where procedural tools are starting 
to bust out of the random-numbers 
racket. Academic researchers have 



been experimenting for years with 
tools for algorithmically generating 
buildings, or even whole towns, 
using the same basic strategy 
that tree simulators apply to trees 
(see Resources). 

All houses are unique (many 
suburbs excepted) but, like trees, 
they do follow certain predictable 
rules. Indeed, real-world architects 
have long recognized this fact: For 
more than a hundred years, some 
communities in the U.S. have used 
"pattern books" to put together 
their homes out of a library of 
elements. Christopher Alexander's 
classic book A Pattern Language, 
devoted to codifying some of 
these rules and their parameters 
is pretty much required reading 
for architects. It's easy to imagine 
a simple computerized rule set 
and some randomized parameters 
creating entire neighborhoods. 
Indeed, in some parts of the 
country it feels like that's already 
going on. 

Most of the main determinants of 
how a building looks or functions— the 
proportions, the number and 
placement of windows, the pitch of 
roofs, materials, and so forth— can be 
reduced to rule sets and parameters. 
Figure 2 shows a simple example 
generated with Tyson Ibele's popular 
BuildingGenerator script in 3ds Max. 
A close look shows that the individual 
buildings lack clear personalities, but 
the overall effect approximates the 
balance of rhythm and randomness in 
urban space nicely. 
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As the example suggests, 
building and city generators aren't 
quite ready to replace hand-built art. 
However, they can do a great job of 
filling in unimportant areas without 
resorting to traditional game tricks 
like glass walls, three-foot hedges 
that can't be hopped, or endless 
cloning. It's also a lot faster to play 
with some sliders for an afternoon 
than to spend all month building 
a side street half your players will 
never even visit. 

As with trees, procedural 
buildings gain a lot more power 
when they incorporate human 
input. The academic Rome Reborn 
project, for example, produced an 
extremely impressive recreation 
of ancient Rome combining hand- 
built landmarks with procedural 
neighbors (Figure 3). Even the 
procedural buildings included 
hand-made architectural details 
like statuary, scrollwork, and trim 
(Figure 4). A numbers-only city 
simulator might be an interesting 
thought experiment but it seems 
far more likely that game teams will 
use some human input. 

SPEED BUMPS AHEAD 

» Of course, there are reasons why 
this tech hasn't become ubiquitous 
so far. Procedural environments 
are considerably more complicated 
than individual trees or node- 
graph shaders. The complexity 
of authoring is correspondingly 
intimidating. Trees, at least can be 
packaged up as presets! 

Beyond that, there are still 
important technical challenges. As 
procedural environment tools start to 
mature, expect to see issues around 
two big areas (tree sim vets may note 
that many of these have been issues 
in the foliage business as well). 

First of all, procedural tools are 
going to need to learn how to make 
geometry that's game friendly as 
well as attractive. Most games are 
very finicky about the types of 
geometry they'll accept. Procedural 
systems from the academic world 
don't need to worry about things like 
degenerate triangles, sliver faces, 
or player navigation meshes. These 
kinds of problems have prevented 
games from making use of many 
sophisticated CAD tools and high- 
end architectural packages, and 



until they're ironed out, procedural 
environments will be limited, at 
best, to render-only uses. 

Secondly, there's the inescapable 
cost factor. In theory, procedural 
tools offer the potential for big 
memory savings. A single building 
or tree can be stored as nothing but 
a set of parameters and a random 
seed value, rather than a complete 
set of geometry and textures. You 
can see this effect clearly in some of 
the city modeling packages where it's 
possible to cram an entire metropolis 
into less disk space than you'd need 
for a detailed Zbrush head. 

Unfortunately, modern 
graphics hardware doesn't have 
the kind of computing capabilities 
needed to turn those parametric 
descriptions directly into rendered 
pixels— they've got to be turned 
into conventional polys and 
textures first. Disk space savings 
won't alleviate the more critical 
shortage of graphics memory. 
Turning a procedural description of 
a building or tree into renderable 
polys involves a lot of calculation. 
This means that a lot of procedural 
tools run the risk of trading away 
valuable CPU time for less valuable 
disk space— not a great bargain 
unless you're in a specialized genre 
like browser games, handhelds, or 
continually updated MMOs. 

The obstacles to procedural 
content are significant. However, 
they are likely to be overcome 
because the need is so great. Every 
new SIGGRAPH brings new examples 
of progress. And not every challenge 
needs to be met before these tools 
become useful: even if procedural 
tools are never used at runtime, 
they will still be good for generating 
a lot of the low-priority content we 
currently build by hand, much the 
way tree sims are used today. 

SHALL WE PROCEED? 

» Working in a technological 
medium is unsettling. You can't help 
but wonder if the computational 
wizardry that brings our ideas to life 
may someday render us obsolete. 
Texture artists used to fear digicams, 
modelers muttered about scanners, 
animators loathed mocap ... you get 
the idea. Even worrywarts, though, 
can see that procedural tools 
aren't much of a threat to either the 



aesthetic or the technical side of 
your job. It's not time to panic. 

On the other hand, don't be too 
complacent either. The economic 
forces shaping our business 
suggest that procedural tech 
is going to evolve, and rapidly. 
Computers may never put us out 
of business, but they certainly will 
change the way we do business. 
Hopefully game artists, combining 
old-school aesthetics with a splash 
of technological savvy, will be able 
to push these emerging tools in 
directions that work as well for 



MFA students as CS whizzes, with 
a little more brushwork and few 
less sliders. At any rate, it still beats 
boiling dead sheep. S 



STEVE THEODORE has been pushing pixels 
for more than a dozen years. His credits 
include MECH COMMANDER, HALF-LIFE, TEAM 

Fortress, Counter-Strike, and Halo 3. He's 
been a modeler, animator, and technical 
artist, as well as a frequent speaker at 
industry conferences. He's currently a 
consultant helping game studios perfect 
their art tools and pipelines. Cmail him at 
stheodore@gdmag.com. 
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Commercial software 

BINARY WORLDS Maker of the Decensor Engine, middleware which generates procedural 
urban landscapes and renders them on the fly. www.binaryworlds.com. 

PROCEDURAL, INC. Maker of City Engine, the software used in the Rome Reborn project. 
www.procedural.com. 

SPEEDTREE Maker of SpeedTree tree modeling software www.speedtree.com. 

XFROG Maker of the Xfrogtree generating software and plugins for Maya, Cinema 4D, and 
Terragen www.xfrog.com. 

Academic sources 

Peter Wonka at the University of Arizona has produced a number of papers related to 
procedural generation of cities with realistic roads, transit networks, and zoning, www. 
public.asu.edu/ffpwonka/Publications/publications.html. 

Pascal Mueller of the Swiss Federal Institute of Technology has been studying procedural 
cities for several years. He's also one of the founders of the commercial firm Procedural 
Inc. www.vision.ee.ethz.ch/ffpmueller/wiki/CityEngine/Documents. 

The Virtual Terrain Project includes links to a number of procedural terrain, foliage, and 
building projects: http://vterrain.org. 
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SURFING THE LOOP 



A DEFENSE OF STRUCTURE IN GAME SCORES 




THERE WAS ATIME WHEN VIDEO GAME MUSIC HAD A LOT TO SAY. SOMETIMES 

it said "Hey, player! Your health is low!" Other times it would be "Congratulations 
for beating the level!" Still, other times it would say "You're powerful now! 
Time to kick ass!" 

These days, video games have grown more sophisticated in the way 
they communicate with the player. User interface and art have evolved 
alongside game audio and each component need not be so blunt in 
communicating important information about the game. In fact, in current 
game scores, you're more likely to hear concepts outside the purely formal 

elements of game 
design. Where an 
earlier game about 
platform traversal 
might have given 
the player a simple 
reward stinger 
upon reaching the 
top of a building, 
Jesper Kyd's score 

for ASSASSIN'S CREED II communicates the deeper emotions present in having 
scaled a particularly tall edifice. Rather than just acknowledge a game 
action well done, the five-second stinger highlights the loneliness that can 
exist when one is so close, yet so far from the bustling city below. 

Not all video game scores are so communicative, however. Despite 
the evolution of game audio, many modern scores seem content sitting 
in the background. They sound awesome, courtesy of big orchestras and 
masterful mixing, but they do not actually connect with the player. Sure, 
sounding cool is a nice thing, but I sometimes wonder if some of today's 
music composers are scared of saying anything. 

AMERICA'S MOST DRAMATIC PASTIME 

» American football is a game full of bits and pieces. In the average three- 
hour game, despite the one hour game clock, spectators are treated to a 
mere 15 minutes of action divided among 120-some plays from scrimmage. 
A person who doesn't know the game might be turned off by the constant 
stoppage of play, whether it be due to a successful tackle or the officials 
throwing yellow flags everywhere. Compared to the continuous, flowing nature 
of a game like soccer, gridiron football is incredibly rigid in its structure. 

It's that structure, though, that makes the game so dramatic. Spectators 
learn to recognize the bits and pieces: the snap, the first down, the 
interception, and so on. Particularly exciting examples of these individual 
components are given names ("The Music City Miracle" or "The Immaculate 
Reception") and spoken about in not-so-hushed tones for years after. 

Of course, the game music world has moments like that as well. Start 
whistling the MARIO theme on a college campus and you're liable to get 
four-part harmony joining you after a few measures. You might get a 
similar reaction with ZELDA, CONTRA, MEGA MAN, and others from years 
past. Examples from modern game music history are more difficult to 
come by. HALO is full of memorable music moments: the choral melody 
on the title screen, the rousing four note action motif, even the loading 
screen choir; at almost a decade old, however, does it really count 
as modern? MODERN WARFARE 2 had a fine sounding soundtrack that 



matched well with the game play, but I honestly cannot hum any of the 
score's parts. I connected with many of the game's action set pieces, but I 
couldn't rememberthe music. 

Maybe this was due to the looping nature of music back in the day. For 
example: CASTLEVANIA ll's adored Bloody Tears is a mere 30 second loop. 
Does the loop itself make it loved? 

I've come across many in the industry who bear nothing but hatred for 
loops. Nowadays, I have a quote from composer John Cage in my arsenal: 
"If something is boring after two minutes, try it for four. If still boring, then 
eight. Then sixteen. Then thirty-two. Eventually one discovers that it is not 
boring at all." 

Now, don't take this as simply a defense of looping music; rather, let's go 
back to the football example. American football has become an incredibly 
successful industry. The football world is replete with storylines, filled with 
drama. Some drama comes from the game itself, but much of it comes from 
journalists, commentators, and fans. They inject story into the structure that 
football has provided, surrounding memorable points like touchdowns and 
player injuries with joy, sadness, and every emotion in between. 

Similarly, video game players the world over have connected their own 
emotions and memories to pieces of video game music. The FINAL FANTASY 
victory theme gets the endorphins going while the MARIO "game over" stinger 
elicits pangs of nostalgia. Today's game music, however, has me wondering: 
Where can I hang my emotions? Where can I connect my memories? 

INTERACTIVE AUDIO SHOULD INTERACT WITH THE PLAYER 

» When I listen to modern video games, I sometimes ask myself if the music 
composer or audio designer is somehow afraid of structure. In today's world 
of interactive music, I sometimes struggle to hear anything that sounds 
like a song's beginning or end. Seconds might pass before I realize that a 
transition between pieces has taken place. Are today's musicians that scared 
of the players hearing the structure of the music? Sure, let them listen to 
the awesome drums and strings, but god forbid they recognize the piece's 
beginning or end ... or even worse: a loop point! 

Some audio designers and composers out there enjoy modern game 
audio tools because of their ability to subvert the music's structure. This 
is a powerful thing that can have a huge effect on the player's overall 
experience. But the structure is not something that is separate from the 
music. It is the music. Structure is sometimes more important than the 
actual notes; while many can't tell the difference between a clarinet and 
a bassoon, they can tell the difference between a new piece of music and 
transitional material. They might not know the whole melody, but they can 
recognize the entrance of that melody, and that's enough to connect with it, 
to hang their emotions on it, to have the music speak to them. 

At many a football game, some attendees don't understand the 
intricacies of the game; concepts like pass interference and intentional 
grounding are lost on them. However, the structure of the game allows 
them to soak it all up, to find points to hangtheir emotions on, and even if 
they don't know all the language, allow the game to speak to them. S 

VINCENT DIAMANTE is a music composer and educator in the Los Angeles area. He penned 
the score for ThatGameCompany's FLOWER and currently teaches at the Interactive Media 
Division at USC. Email him at diamante@gmail.com. 
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Hired someone interesting? Let us know at editors@gdmag.com! 



brett seyler joins unity 




ENGINE COMPANY UNITY 

Technologies recently 
announced the hiring 
of Brett Seyler, who 
previously oversaw 
development of the 
directly competitive 
Torque engine for 
InstantAction and 
GarageGames. He will 
now be Unity's VP of 
strategy. We caught up 
with him to see why he 
made the switch, and 
to get advice for those 
looking to move to a 
competitor. 

Why did you decide to 
make the switch from 
GarageGames to Unity? 
Brett Seyler: What, no 
warm up questions? 
Hah! Okay, right to 
it ... First, leaving 
GarageGames was no 
easy decision, it was 
a great experience 
and I have very few 
regrets. I was lucky 
enough to work with 
some truly brilliant 
people. Josh Williams 
(a phenomenal young 
CEO) and the company 
founders had an exciting 
vision for growing the 
company further with 
InstantAction and 



games. It was great to 
be a part of that and 
work with them in a 
variety of roles. For 
the past two years 
at GarageGames, my 
primary responsibility 
was leading the Torque 
business, in all aspects. 
In that capacity, I got to 
see a relatively young 
development team grow 
by leaps and bounds 
and it showed in the 
releases we shipped. 
In 2009, 1 think Torque 
moved forward faster 
than at any time in its 
past. I have to credit 
that modest, but very 
effective team with that 
accomplishment. 

In July last year, 
the company saw major 
changes. We brought 
on a new CEO, Lou 
Castle, and decided to 
close the company's 
Eugene HQ, relocating 
the employees there to 
Portland for platform 
development and Las 
Vegas for games and 
Torque. I want to say 
that in my short time 
working with him, Lou 
was really great. He 
lived up to his stellar 
reputation and was very 



supportive during what 
could have been a much 
more difficult period of 
transition. Nevertheless, 
these changes and 
others were no longer a 
good fit for me. I wanted 
to be at a younger, 
smaller company again, 
and yet, I still felt very 
passionately about the 
kind of work I was doing. 

In truth, I'd been a 
closet fan of Unity as a 
company for quite some 
time. I've watched them 
craft and deftly execute 
a great strategy that 
has allowed them to 
grow faster than anyone 
else in this space. Even 
when I was running 
the Torque business, 
I always had a good, 
friendly relationship 
with David Helgason, 
and others. I was killing 
myself trying to find 
ways to beat them of 
course, but I almost 
always came away 
impressed with how 
they managed their 
young company. I also 
knew that if I joined, I 
could add significantly 
to their already 
impressive momentum. 
I'd been spending 18- 
hour days for more 
than two years thinking 
about how to succeed in 
this space and I didn't 
want all those ideas to 
go dim or my passion 
to dwindle. In the end, 
Unity offered me the 
perfect opportunity to 
see these ideas and 
ambition come to life. 
What's more, my vision 
to invest heavily in the 
rapidly-changing web 
and mobile markets, 
and for adapting to their 
evolution were eerily 



in alignment with the 
Unity founders. It just 
felt right. 

Was there something 
you were looking for 
in your career that 
you couldn't get at 
GarageGames? 
BS:Yes. I wanted to 
be back at a smaller 
company with greater 
control of its destiny. 
People talk about the 
day the "soda is no 
longer free." It's an 
apt saying. I strongly 
prefer the intensity 
and passion of start- 
up culture to bigger 
companies. If I hadn't 
found such a great fit at 
Unity, I would probably 
be doing something 
much smaller still. I've 
always been inspired 
by what a few driven, 
talented people can 
do. It's an addictive 
lifestyle, the excitement 
of it. 

Any advice for someone 
that wants to move from 
one company to a major 
competitor? 

BS: Don't be hasty. Treat 
the people you leave 
behind they way you'd 
want them to treat 
you. Do it for the right 
reasons. Money is rarely 
the right reason. For me, 
San Francisco was the 
city I wanted to live in. I 
love games, technology, 
and the unique culture 
that comes with working 
in a start-up. I have to 
work with people I trust 
and believe in. Unity fit 
all these criteria and so 
many more. I couldn't be 
happier with my choice! 
—Brandon Sheffield 



who went 
where? 



Niccolo de Masi, former president 
of Hands-On Mobile, has been 
hired by Glu Mobile as the 
company's new CEO replacing 
Capcom alum Greg Ballard. De 
Masi hopes to help bring the 
company to new social platforms. 

Dave Gatchel, former general 
manager of Paradigm 
Entertainment, has been tapped 
to run THQ's new Montreal studio, 
also as general manager. This 
brings THQ's Canadian studios 
up to two, alongside Relic 
Entertainment. 

Atari has replaced CEO David 
Gardner with COO Jeff Lapin, 

who will be the company's new 
chief executive officer. It has 
been announced that Lapin will 
earn a yearly base salary of 
€400,000 ($583,960), and if 
he meets certain performance 
criteria such as the release 
of games on time and within 
budget, and meeting the 
company's financial goals, he 
can earn up to an additional 
€200,000 ($291,980). 

Bonfire Studios, one of the 
many companies formed from 
the ruins of Ensemble Studios, 
has hired on Dave Pottinger, 
an Ensemble alumnus, to be 
an engine lead and technology 
director, similarto his role at 
Ensemble in the past. Pottinger 
was also lead designer on HALO 
WARS, Ensemble's last product 
before being closed by parent 
Microsoft. 

NBA JAM, SMASH TV, and NFL 
BLITZ creator MarkTurmell has 

become the new senior creative 
director at Electronic Arts' 
Tiburon studio, where he'll focus 
on EA Sports football franchises 
like MADDEN, but also spearhead 
NBA Jam's contemporary return 
on the Wii. 
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EDUCATED PLAY! 



the devil's tuning fork 



ECHOES IN THE DARKNESS FROM DEPAUL UNIVERSITY'S GAMING ELITES 



The Devil's Tuning fork is a 

visually arresting game by students 
from the Game Elites program 
at DePaul University in Chicago. 
Taking its visual cues from M. C. 
Escher, THE DEVIL'S TUNING FORK 
presents a night world of illusionary 
architecture that can only by 
navigated with the aid of reflected 
sound waves. The result is both 
unsettling and coldly beautiful. We 
spoke with producer Matt Lazar, 
project lead and tech lead Jason 
Pecho, and visual design lead Kyle 
Sullivan to find out more about this 
unique gaming experience. 

How were students chosen for the 
DePaul Game Elites program? 
Matt Lazar: From 40 original 
applicants, 14 were chosen by 
the team's faculty advisors: Alex 
Seropian, Patrick Curry, Bill Muehl, 
Joe Linhoff, and Scott Roberts. One 
person was added later. 

THE DEVIL'S TUNING FORK team is 
fairly large. Did that present any 
organizational challenges? 

ML: It was easily the largest group 
any of us had ever worked in 
before. We learned so much about 



THE DEVIL'S TUNING FORK 

www.devilstuningfork.com/index.php 



teamwork. Every month we became 
more organized. We started 
having multiple meetings each 
week, established clear, concise 
milestones and kept notes. A big 
step was choosing leads to make 
final decisions. By fall, we had 
become a much more efficient and 
disciplined unit. 

Six months from start to a finished 
and nicely polished game is pretty 
remarkable. How quickly were you 
able to nail down the final design? 

ML: We did not nail down the final 
design until the fourth month, 
leaving us only a couple months 
to make the actual game. Our first 



month was spent considering 
various concepts. We prototyped 
several ideas and after we settled 
on the idea of using echolocation 
for game play, we experimented 
with the look of the game and 
how it should play— which took 
more testing and time. It was a 
constantly evolving process. One 
of the lessons we learned was that 
you can never have enough testing. 
Another was that moving too 
quickly from the prototyping stage 
can only cause problems. 

What aspect of the game's 
development was the most the 
most difficult? 

ML: Story became one of the most 
challenging aspects to figure 
out. Because the mechanic of 
echolocation was something we 
had never seen before, it was hard 
for us to come up with a storyline to 
match it. We had plenty of internal 
debates about what it could be 
or if we even needed a script. Not 
until late into development did we 
finalize the story concept. 

To expedite the process, we 
created a story strike team to 
write the dialogue, storyboard 
scenes and direct the voice-acting 
sessions. It was rapid development, 
but story ended up being integral to 
the final experience. 

Can you tell us a little about the 
QE Engine that Joe Linhoff, your 
faculty advisor, created? 
Jason Pecho: The QE engine is a 
light-weight OpenGL engine made 
for educational purposes that acts 
as a thin layer between the game 
and the computer. It has grown 
steadily since Joe introduced it to 
DePaul University for student use a 
couple years ago. The major benefit 
of the engine was that it allowed 
us to not worry about interfacing 
with Windows and instead focus 
solely on the game itself. The engine 
also comes with a few tools to help 
development along. It parses Maya 




files into a suitable format, for 
instance. In effect, this made Maya 
not only the art team's tool of choice 
but also our level editor. We did 
have to write a bit of pipeline code, 
but the engine handled most of the 
translation from Maya to the game. 

Afewofthe student 
programmers were familiar with 
QE before the project started, but 
some ramp up time was involved. 
Even those who had experience 
with QE were constantly learning 
new features as the development 
progressed. In addition, the art 
team had to be educated on the 
art pipeline to get their models 
from Maya into the game. Overall, 
everything worked out quite well. 

How was it working with Alex 
Seropian? What was the best bit of 
guidance that he gave the team? 
Matt Lazar: It was great working 
with Alex. He was so helpful during 
the concept and prototype phase. 
Each team member presented at 
least one idea for the project and 
Alex gave feedback not only on 
what would work, but what needed 
more detail. The whole process 
prepared us for the months to 
come. Plus we spent a month of our 
summer talking about video game 
ideas with a principle creator of 
HALO. Could there be any better way 
to spend your summer? 

As for his best advice, Alex 
said that when you are creating a 



timeline for the development of a 
game, you should plan to have it 
done approximately halfway to your 
final deadline because inevitably a 
game will take twice as long as you 
think it will. He was right. 



How did you arrive at the look 
of the game? Did going with a 
more abstract style make asset 
creation easier? 
Kyle Sullivan: We put a lot of hard 
work into making the game as 
visually polished as possible. Our 
visual design process involved a lot 
of experimentation and iteration. 
Nobody had made a game about 
echolocation before, so we had 
to start with concepts, try them 
out in-game, then go back and fix 
everything that didn't work. We 
followed this technique for the 
entirety of the development process. 

As far as asset creation goes, 
the abstract style of our game 
didn't really make anything 
easier. Because we were working 
with an untested style, we had to 
take many different things into 
consideration to keep it unified. For 
example, all assets had to adhere 
to our Italian Renaissance/MC 
Escher aesthetic. This meant 
following a large list of design 
rules. If anything, I'd say that 
our style made our game concept 
more accomplishable and more 
fun to make. 

—Jeffrey Fleming 
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Make Your Creative Passion Your Career 

If you've ever dreamed of engaging your creative side full time, 
National University's School of Media and Communications can 
help you do it. Earn a bachelor's or master's degree in today's 
most fulfilling and creative fields. 

National University makes it convenient to get your degree with 
its one-course-per-month format and classes offered online or at 
12 Southern California campuses. 



Areas of study include: 

-Digital Cinema 

-Digital Entertainment 
and Interactive Arts 

-Digital Journalism 
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-Professional Screenwriting 

-Strategic Communications 
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UNIVERSITY. 

fullsail.edu 

Winter Park, FL 
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BECOME A MASTER OF DIGITAL MEDIA 



We offer a 20-month master's degree in entertainment technology and digital 
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real world projects, and a 4-month internship in Vancouver, Canada: videogame 
capital of the world. 
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Care about games? It's time to join the conversation. 
Game Design Expo 2010 is where game industry 
leaders, up-and-coming game designers, and anyone 
passionate about games unite. This two-day event, 
hosted by Vancouver Film School's acclaimed 
one-year Game Design program, brings together 
the industry's top minds in one of the world hubs 
of game development. 

■ Industry pros and like minds come together 
in beautiful Vancouver, BC r Canada 

■ Presentations by key creative movers from 
companies like BioWare and Obsidian 

■ Free Open House at VFS's Game Design 
program, including sample classes 
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Now accepting applications. Apply today! 
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YOUR ANNUAL REVIEW 



THIS IS FOR YOUR OWN GOOD 



I JUST WANT TO PREFACE 

this by saying it's really 
great that the game you 
worked hard making art for 
shipped on time to great 
reviews and made lots of 
money! But before you 
celebrate, let's talk about 
your performance over the 
last year. I've spoken to 
many people about you, 
and they gave me all kinds 
of little tidbits on your 
character that I've worked 
into this report here, which 
I'm now readingto you. 

Well, it pains me to say 
this, because I want to like 
you— believe me, I do— but 
as it turns out, you're not 
so hot. Certainly not as hot 
as we thought you were 
when we hired you. In fact, 
it turns out you actually 
have certain traits that 
could be viewed as needing 
work. Fallibility wasn't 
something we identified in 
our interview of you, but 
now that it has suddenly 
come up, I must admit it is 
of some concern to your 
future here. 

Thankfully for you, 
however, I am your ally. And 
I want to see you succeed- 
almost as much as you do. 
Therefore, in order for you to 
accomplish what we define 
as success, here are the 
traits I expect you to work 
on in the next year. 

Impolitic. 

First of all, I want you 
to know that while I, 
personally, think it's cute 
the way you say what you 
really think in meetings and 
so on, you should probably 
cut it out. People here don't 
want to hear what you 



think— I mean, if they did, 
they would be your buddies, 
right? And since you don't 
have "buddy status" with 
anybody important, you 
really ought to just shut 
your mouth and do as 
you're told. 

Disagreeing with people 
isn't just bad for your career, 
it also creates a political 
issue that I have to step 
in to remedy. You're lucky 
that I'm such a smooth guy. 
Anyway, just keep in mind 
that opining is not what we 
hired you for— nor is it what 
we pay you for— and you're 
starting to get the idea. 

Impetuous. 

In our Employee Handbook 
—which we really are going 
to put down in writingthis 
year— there is a rule saying 
that nobody is allowed 
to CC: the art director 
on anything concerning 
normal maps. However, I 
have it on good authority 
(I won't say who— let's 
just say it is a certain 
person who directs the art 
around here) that you did 
this. Needless to say, you 
must absolutely follow 
the rules as described in 
the Employee Handbook, 
or else you are subject to 
disciplinary action up to 
and including undergoing 
"exceptional punishments," 
which I won't describe here 
in this meeting. But if you're 
curious, you'll find them 
explained in the Employee 
Handbook. 

Passive. 

Often times, I've seen you 
wait forthings to happen 
before you react to them, 




instead of just taking the 
initiative to make things 
up, as we expect of our 
more superior employees. 
For example, you told me 
you were waiting to find 
out what the design of the 
character was before you 
started modeling it. What 
was that all about? Next 
year, please take more 
initiative like your peers, 
and start doing things right 
away whether the character 
has anything decided 
about it or not. It says here 
that you made some weak 
excuse about "wanting 
definition" first, which is 
rather unfortunate. 

Empathetic. 

You seem to be actually 
concerned about the 
welfare of others you work 
with. It says here you 
pointed out that one of your 
colleagues wasn't going 
to get credit for his hard 
work. Another co-worker of 



yours told a story about the 
time you made a big stink 
about whether we were 
doing the right thing in our 
dealings with our outsource 
labor camps. I mean our 
outsourcing partners. 

While Ithinkthat 
attitude is endearing, if 
you didn't concern yourself 
with such things I think 
you'd find your days getting 
easier. In fact, let me say 
something off the record: 
you seem like a pretty 
smart guy. So why don't 
you immediately grasp that 
the way we do things is, 
unquestionably, the best 
possible way? I just don't 
understand it. 

Human. 

So, remember that time we 
changed the proportions of 
every character in the game 
and didn't tell you until a 
week before that big, major 
deadline? And you said 
you had to reanimate them 



all without enough time to 
doit, and told us it wasn't 
actually possible? Well, we 
see this as a major failure 
on your part. You might 
respond, "I'm only human," 
and there you go, you've 
admitted the deficiency 
right there. Please work on 
this. Please. 

Well, that about wraps 
things up! If you don't have 
any questions— and it 
certainly seems like you 
don't— just sign here, on 
this line. Great! So how's 
the family, by the way? 
Any exciting plans forthe 
weekend? No? Well, bye 
then, and here's looking 
forward to another year 
of contributing to the 
company's success! ($) 

MATTHEW WASTELAND 

writes about games and game 
development at his blog, 
Magical Wasteland (www. 
magicalwasteland.com ). 
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Autodesk® Kynapse® 

With the demands of more 
realism in games, how can 
artificial intelligence help add 
to the sense of immersion 
for players? We find out how 
Autodesk Kynapse middleware 
can be used in a common 
scenario to provide realistic Al 
for games. 
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Autodesk Kynapse in action: In this scenario, three bodyguards automatically provide cover for a user-controlled player. 



Heightening Realism with In-Game 
Artificial Intelligence 

With the technological power of 
today's consoles and PC's, gamers are 
demanding more realism than ever. In 
the challenge to create truly immersive 
gameplay, artificial intelligence is 
paramount to giving users an immersive 
experience. In this article, we look at a 
common, but challenging game scenario 
and how the Autodesk® Kynapse® 
artificial intelligence middleware can help 
solve this challenge through 3D spatial 
awareness, 3D path-finding and team 
coordination. 

In a combat game scenario, we have a 
player controlled character, and three 
computer-controlled bodyguards 
that follow the player and protect it. 
Wherever the player goes in the level, 
the bodyguards will automatically 
identify key areas where an enemy could 
shoot at the player. The bodyguards 
will use this information and move into 
the appropriate position to protect the 
player. This scenario would be used in 
games where a player character has 
computer-controlled team members that 
need to move through a level with the 
player and assist. 

The Al that drives this kind of behavior 
is achieved through the use of Kynapse. 
Spatial awareness libraries help each 
entity identify in real-time the key 
topological zones where an enemy 
could hide and shoot from. This includes 



windows, street corners and access ways. 
These key zones can be automatically 
generated through the Kynapse toolset, 
or manually tagged by level designers. 
What is interesting about this scenario 
is the realism of the solution - when 
the player is positioned against a wall, 
none of the bodyguards will face the wall 
because no threat can come from the 
wall. 

To move the characters into their 
appropriate positions, we use the 
Kynapse 3D path-finding library. This 
enables each character to find their way 
to their target positions in the level, 
while dynamically avoiding objects 
and other characters. In this scenario, 
characters only have to move a short 
distance, but the Kynapse library can also 
cater for very large maps such as those 
used in role-playing games. In such cases, 
Kynapse can utilize hierarchical path- 
finding technology, which provides an 




elegant and highly optimized solution for 
helping characters find their way across 
larger worlds. 

Finally, the "bodyguards" scenario uses 
team coordination to ensure that each 
character doesn't go to the same spot. 
Through the use of the Kynapse libraries, 
each character can share information, 
just like a real team would. The result is 
that each character intelligently moves 
into a position that could protect the 
player in the most sensible way, which 
heightens reality and gives players an 
immersive experience of being protected 
by comrades on the battle-field. 

This is just one scenario that shows how 
Kynapse can be used to solve a complex 
Al challenge in games. In such a case, 
developing your own Al solution might 
be prohibitively expensive due to the 
cost of research, development, testing 
and implementation. With Kynapse, the 
solution is "off-the-shelf" and ready to 
integrate into your game. 

To see Kynapse in action (including the 
above scenario and others), we invite you 
to watch the Introduction to Kynapse 
video at www.autodesk.com/kynapse. 

For more information about Kynapse and 
Autodesk Middleware, please contact us 
at middleware@autodesk.com. 



Kynapse spatial awareness in action: the body- 
guards do not face the wall as no threat can 
come from it. 
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Autodesk and Kynapse are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other coun- 
tries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product offerings and 
specifications at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document. ©2009 Autodesk, 
Inc. All rights reserved. 
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